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ABSTRACT 


In  examining  the  recent  trend  of  the  Client  /  Server  computing  technology,  it  can 
be  seen  that  distributed  object  technology  is  ready  to  take  off.  The  CORBA  (Common 
Object  Request  Broker)  architecture  is  the  most  widely  known  and  readily  available 
candidate  for  development.  For  this  reason  CORBA  has  attracted  our  attention. 

The  OMG(Object  Management  Group),  a  consortium  of  object  venders, 
developed  the  CORBA  standard  in  the  fall  of  1990  as  a  common  interconnection  bus  for 
distributed  objects. 

Transaction  processing  is  useful  not  only  in  database  applications  but  also  in 
building  robust  mission-critical  applications.  Utilizing  CORBA  one  can  build  reliable 
distributed  software  systems  in  a  much  easier  way. 

CORBA  is  the  most  widely  accepted  standard  in  this  field  and  there  are  many 
CORBA  implementations  available  now.  Moreover,  the  transaction  concept  is  the  key  to 
ensure  the  reliability  and  availability  of  Client  /  Server  applications. 

In  this  thesis  transaction  properties  were  applied  to  a  database  application 
program  based  on  Naval  Post  Graduate  School’s  Course  Iteration  System.  For  this 
purpose  an  Object  Transaction  Service  was  provided  based  upon  the  CORBA 
architecture.  It  takes  advantage  of  object-oriented  programming  to  help  programmers 
implement  transactional  applications  in  a  much  easier  way. 

In  late  1994,  the  OMG  also  published  the  specification  for  the  object  transaction 
service.  This  specification  is  adopted  as  the  blue  print  for  this  study.  This  thesis  presents 
the  implementation  and  integration  of  the  object  transaction  service  based  on  CORBA. 

JDBC  (Java  Database  Connection)  was  not  used  for  transaction  property,  because 
JDBC  is  currently  limited  in  that  it  cannot  manage  transactions  across  multiple 
connections.  For  transaction  support  across  databases  or  object  services,  CORBA's 
Transaction  Service  provides  the  best  level  of  abstraction. 
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I.  INTRODUCTION 


A.  OVERVIEW 

A  thesis  usually  begins  with  a  general  review;  instead  I  will  ask  some  questions  to 
make  the  subject  more  understandable  after  giving  the  general  definition  of  thesis. 

This  thesis  was  based  on  a  real  application  that  is  used  by  the  Naval  Post 
Graduate  School  course  registration  system.  This  implementation  simulates  that  students 
from  different  curricular  can  enter  their  course  requests  to  a  database  table  instead  of 
hard  copy  signup  sheet.  This  system  supports  students  concurrent  attempts  to  update  their 
account  with  a  transaction  property.  Students’  interaction  was  simulated  to  add  a  course 
from  Course  Table  to  Registered  Course  table  and  drop  a  course  from  the  Registered 
Course  table  corresponding  to  the  name  of  the  students.  This  thesis  implements  and 
integrates  the  transaction  service  to  this  Course  Registration  Database  application 
program.  The  following  questions  were  asked  to  identify  the  definition  of  Transaction 
Service. 

•  What  happens  if  a  failure  occurs  during  modification  of  resources? 

•  Which  operations  have  been  completed? 

•  Which  operations  have  not  (and  have  to  be  done  again)? 

•  In  which  states  will  the  resources  be? 

Whatever  measures  are  taken  to  avoid  failures,  failures  still  occur.  Power  supplies 
may  fail,  disks  crash  and  operating  systems  may  not  supply  the  stability  we  hope  for. 
Assume  that  such  a  failure  occurs  while  one  component  updates  resources  from 
belonging  to  other  components.  For  example  during  course  registration  ,  while  adding  or 
dropping  courses  from  the  Course  Registration  Database.  This  database  consists  of  two 
tables;  a  Courses  table  that  lists  available  Computer  Science  courses  and  a  Registered 
Course  table  that  is  updated  when  Computer  Science  students  add  and  drop  new  courses 
at  the  beginning  of  each  quarter.  This  action  performs  two  primitive  operation 
invocations:  adding  a  new  course  from  the  Course  table  and  dropping  a  course  from  the 
Registered  Course  table. 
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If  a  failure  occurs  during  the  operation,  a  number  of  questions  arise: 

Which  actions  have  been  completed  and  which  have  not?  In  the  case  of  course  updating, 
has  the  add  operation  been  completed  but  the  drop  operation  not  completed?  What  is  the 
state  of  the  resources?  Are  there  any  operations  necessary  to  restore  their  integrity?  In  the 
case  of  adding  a  course  has  the  course  that  was  on  its  way  from  one  table  to  the  other 
table  been  lost  and  does  it  need  to  be  recovered? 

The  approach  taken  in  both  databases  and  distributed  systems  to  deal  with  these 
problems  are  transactions.  A  transaction  is  a  sequence  operation  that  is  either  performed 
completely  or  not  at  all.  If  it  is  completed,  the  effect  of  a  transaction  is  persistent  and 
cannot  be  affected  by  failures. 

“ Transactions  are  more  than  just  business  events;  they  have  become  an 
applications  design  philosophy  that  guarantees  robustness  in  distributed  systems.”[l] 
Traditionally,  we  use  the  transaction  concept  when  we  need  to  perform  a  set  of  atomic 
operations  on  a  database  to  ensure  the  consistency  of  shared  data.  But  the  transaction 
concept  is  not  only  useful  in  the  database  domain.  It  is  impossible  to  create  a  mission- 
critical  client  /  server  application  without  the  need  to  update  some  data.  Transactions 
have  become  common  and  desirable  services  to  construct  reliable  and  available  client  / 
server  applications. 

“The  concept  of  transactions  has  been  successfully  applied  in  many  commercial 
data  management  systems  to  build  robust  and  reliable  systems.”  [2]  As  network 
technology  grows,  the  environment  of  distributed  computing  is  becoming  more  and  more 
mature.  This  motivates  the  introduction  of  transaction  concepts  into  distributed 
environments.  As  we  can  see,  this  concept  has  dominated  the  world  of  database 
processing. 

Taking  a  look  at  the  recent  trends  in  client  /  server  computing  technology,  it  is 
easy  to  see  that  distributed  object  technology  is  ready  to  take  off.  What  is  a  distributed 
object? 
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If  you  have  experience  writing  programs  in  an  object-oriented  language  like  C++ 
and  Java,  you  will  not  be  unfamiliar  with  the  word  “object”  in  an  object-oriented  world. 
An  object  is  a  functional  unit  of  a  program,  which  encapsulates  code  and  data,  and  can  be 
specialized  by  means  of  inheritance.  Naturally,  an  object  cannot  reach  across  the 
compiled-language  and  address  spaces  in  a  traditional  programming  environment.  It  is 
clear  that  in  order  to  introduce  the  object-oriented  concept  into  client  /  server  computing, 
we  have  to  break  these  limitations. 

A  distributed  object  is  a  binary  component  that  can  be  accessed  from  clients  in 
remote  hosts  by  means  of  method  invocations  through  a  common  software  bus.  Clients 
have  no  idea  what  language  was  used  to  create  the  objects  or  even  the  physical  locations 
of  these  server  objects.  Clients  need  only  know  the  names  and  interfaces  that  server 
objects  export  to  the  software  bus.  So  we  can  draw  the  picture:  every  component  ties  to 
the  common  software  bus  to  publish  their  interfaces  after  which  these  components  can 
interoperate  with  each  other,  forming  the  basis  of  client/server  computing.  “Distributed 
object  technology  inherits  the  advantage  of  object-oriented  programming  allowing  large 
applications  to  be  broken  into  small  and  manageable  components  that  coexist  on  the 
intergalactic  bus”[7].  We  can  say  that  distributed  object  technology  promises  the  most 
flexible  client  /  server  computing  model. 

B.  BACKGROUND 

In  the  transaction  processing  world,  all  products  support  transaction  services  over 
heterogeneous  platforms,  however,  none  of  them  support  the  object-oriented  paradigm. 
There  are  several  different  approaches  to  distributed  object  technology.  Two  of  the  most 
well  known  distributed  object  infrastructure  standards  are  Microsoft's  DCOM[3]  and 
OMG's  CORBA[4], 

Each  of  them  takes  a  different  approach  toward  object  distribution. [3,5] 
Compared  to  the  CORB  A  object  model,  DCOM  must  be  considered  weaker  since  it: 

•  does  not  support  inheritance  of  components 

•  is  not  as  strongly  typed 

•  does  not  support  exceptions 
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“The  OMG  has  adopted  an  internetworking  specification  between  the  two  object 
models.  It  will  be  refined  into  an  interoperability  specification  and  enable  DCOM  objects 
to  invoke  services  from  CORBA  objects  and  vice  versa”[6].  The  main  difference  is 
DCOM  does  not  support  the  inheritance  feature  of  object-oriented  technology  and 
originally  aims  at  document  processing.  CORBA,  on  the  other  hand,  is  aimed  at  general 
purpose  distributed  computing. 

A  standard  is  necessary  to  pave  the  way  toward  success.  The  OMG  (Object 
Management  Group)  specifies  an  architecture  for  an  open  software  bus,  called  CORBA 
(Common  Object  Request  Broker  Architecture)!!].  CORBA  which  is  proposed  by  OMG 
(Object  Management  Group)  is  the  realization  of  OMA  (Object  Management 
Architecture),  also  proposed  by  OMG  for  distributed  object  computing.  It  defines  a  set  of 
common  services  that  are  used  to  allow  objects  to  invoke  each  other’s  methods  without 
regard  for  the  platform  on  which  they  operate,  or  the  language  in  which  they  are  written. 
Just  as  Java  provides  independence  at  the  platform  level  CORBA  provides  independence 
at  the  language  and  platform  level,  as  shown  in  Figure  1.1. 

CORBA  consists  of  four  major  parts:  object  request  broker  (ORB),  common 
object  service  specification  (COSS),  common  facility  architecture  (CFA)  and  application 
objects!  1].  The  ORB  serves  as  a  software  bus  that  forwards  messages  between  client  and 
server  objects.  COSS  defines  a  set  of  basic  building  blocks  over  the  ORB.  These  building 
blocks  are  realized  as  server  objects.  COSS  defines  a  number  of  services  that  are  useful  to 
any  application  in  general.  I  chose  to  use  CORBA  as  the  distributed  object  infrastructure 
because  it  is  an  open  standard  and  widely  support  in  heterogeneous  environments. 
Additionally  the  TNRL  (Turkish  Naval  Research  Lab)  directed  the  use  of  CORBA  for 
future  projects. 

C.  PROBLEM  STATEMENT 

The  OMG  does  not  provide  implementations  for  these  services  but  provides  the 
interfaces  by  which  the  services  are  offered.  CFA  specifies  a  few  facilities  that  are  closer 
to  application  level  and  are  closer  to  a  specific  application  domain. 
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CORBA  defines  the  interfaces  and  functionalities  of  the  ORB  via  which  client 
objects  may  reuse  COSS  and  CFA  objects  or  access  other  server  objects.  CORBA 
specifies  an  ORB  (Object  Request  Broker)  through  which  a  client  can  invoke  the  methods 
of  remote  objects  either  statically  or  dynamically.  The  OMG  also  defines  an  DDL 
(Interface  Definition  Language)  to  specify  the  interfaces  between  components  and  the 
software  bus.  IDL  is  independent  of  any  programming  language.  From  the  client’s  point 
of  view,  what  they  see  is  an  IDL  interface  that  a  server  object  exports  and  they  need  not 
know  how  the  server  object  is  implemented. 


D.  OBJECTIVE 

As  mentioned  above,  we  believe  distributed  object  technology  is  the  future  of 
client  /  server  computing.  It  will  make  sense  if  we  can  provide  some  common  services  on 
top  of  the  standard  CORBA  services  to  help  with  the  development  of  distributed 
software.  Because  transactions  are  essential  for  building  reliable  distributed  applications, 
an  object  transaction  service  was  chosen  as  the  first  step  toward  distributed  object 
computing.  The  main  idea  is  to  create  an  ordinary  object  and  make  it  transactional  by 
inheriting  the  interfaces  defined  by  the  transaction  service.  This  enables  it  to  participate 
in  atomic  transactions,  even  in  face  of  failures. 
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The  goal  of  this  research  is  to  explore  and  implement  the  Object  Transaction 
Service  (OTS)  which  is  defined  in  COSS,  on  a  Windows  NT  platform  so  that  application 
object  programmers  can  reuse  these  services  to  build  reliable  and  robust  distributed 
software  efficiently.  OTS  supports  not  only  the  flat  transaction  model  but  also  the  nested 
transaction  model.  Additionally  it  defines  a  set  of  interfaces  for  recoverable  objects,  a 
kind  of  server  object  that  can  recover  its  states  when  suffering  failures. 

E.  SCOPE  AND  LIMITATIONS 

An  application  can  take  advantage  of  the  OTS  as  follows  (Figure  1.2).  In  the 
typical  scenario,  a  client  first  begins  a  transaction  by  issuing  a  request  to  an  object  in 
OTS,  which  constructs  a  corresponding  transaction  context.  The  client  then  performs 
transactional  operations  by  issuing  requests  to  resource  objects.  The  resource  objects  in 
turn  register  themselves  with  the  OTS  and  acquire  locks,  in  order  to  control  concurrent 
access  to  shared  data  items. 
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Figure  1.2  System  Sketch  [From  Ref.  6] 
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Eventually,  the  client  ends  the  transaction  by  issuing  another  request  to  the  OTS 
which  triggers  the  atomic  commit  procedure  to  synchronize  all  objects  involved  in  this 
transaction  on  behalf  of  the  client.  Thus,  OTS  guarantees  the  essential  ACID  properties 
(detailed  in  the  next  chapter)  with  respect  to  the  transaction. 

The  design  of  the  service  consists  of  three  parts:  the  OTS  manager  and  a  suite  of 
libraries  that  help  the  resource  object  programmer  in  creating  a  recoverable  transactional 
object.  Programmers  who  want  to  use  transaction  services  should  inherit  the  OTS 
interfaces  (detailed  in  Chapter  II).  Programmers  who  want  to  provide  objects  to  be  used 
within  transactions  can  use  the  libraries  suite  developed  in  this  thesis.  The  current  version 
of  this  libraries  does  support  both  flat  and  nested  transaction  models  on  the  Windows  NT 
platform. 

F.  ORGANIZATION  OF  THESIS 

This  thesis  is  organized  as  follows:  Chapter  II  introduces  the  CORBA 
environment.  Chapter  III  provides  an  overview  of  the  system.  The  DDL  interfaces  of  the 
Object  Transaction  Service  and  the  system  architecture  is  described  in  Chapter  IV. 
Chapter  V  discusses  the  issues  of  implementing  the  Object  Transaction  Service.  Finally  a 
conclusion  is  presented  in  Chapter  VI. 
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II.  THE  CORBA  ENVIRONMENT 


Our  Object  Transaction  Service  is  built  upon  the  OMG‘s  CORBA  (Common 
Object  Request  Broker  Architecture).  In  order  to  have  a  common  base  for  further 
discussion,  we  review  the  essential  background  about  OMG’s  CORBA  and  some  related 
works.  The  development  environment  is  also  addressed. 

A.  OMG‘s  OBJECT  REFERENCE  MODEL 

The  Object  Management  Group,  Inc.  (OMG)  is  an  international  organization 
concerned  with  object  technologies.  Its  goal  is  to  establish  industry  guidelines  and  object 
management  specifications  to  provide  a  common  framework  for  application 
development.  Primary  goals  are  the  reusability,  portability,  and  interoperability  of  object- 
based  software  in  distributed,  heterogeneous  environments.  OMG  establishes  the  Object 
Management  Architecture  (OMA)  to  provide  the  conceptual  infrastructure  upon  which  all 
OMG  specifications  are  based.  It  is  known  as  OMA  object  Reference  Model. 

1.  Organization  of  The  Reference  Model 

The  Reference  Model  identifies  and  characterizes  the  components,  interfaces  and 
protocols  that  compose  OMG‘s  Object  Management  Architecture,  but  does  not  itself 
define  them  in  detail.  Generally  speaking,  the  Reference  Model:  [1] 

•  Identifies  the  major  separable  components  of  the  total  Object  Management 
Architecture 

•  Characterizes  the  functions  provided  by  each  component 

•  Explains  the  relationships  between  the  components  and  with  the  external 
operating  environment 

•  Identifies  the  protocols  and  interfaces  for  accessing  the  components 
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Specifically,  the  Reference  Model  addresses: 

•  How  objects  make  and  receive  requests  and  responses 

•  The  basic  operations  that  must  be  provided  for  every  object 

•  Object  interfaces  that  provide  common  facilities  useful  in  many  applications 

2.  Components  of  the  Reference  Model 

The  Reference  Model  consists  of  the  following  components:  (Figure  1-1) 

•  Object  Request  Broker,  which  enables  objects  to  transparently  make  and 
receive  requests  and  responses  in  a  distributed  environment.  In  so  doing,  an 
ORB  provides  interoperability  between  applications  on  different  machines  in 
heterogeneous  distributed  environments  and  interconnects  multiple  object 
systems.  Some  details  of  how  to  use  an  ORB  to  develop  distributed  systems 
will  be  shown  in  the  next  section.  [1] 

•  Object  Services,  a  collection  of  services  that  support  basic  functions  for  using 
and  implementing  objects.  These  services  are  independent  of  application 
domains  and  act  as  the  building  blocks  of  distributed  applications.  The 
operations  provided  by  Object  Services  are  made  available  through  the  ORB. 
OTS  is  an  example  of  Object  Services.  [6] 

•  Common  Facilities,  OMG  defines  a  set  of  services  that  many  applications  may 
share,  but  which  are  not  as  fundamental  as  the  Object  Services.  They  are 
usually  domain  specific  services.  For  instance,  a  printing  and  spooling  system 
or  electronic  mail  facility  could  be  classified  as  a  common  facility. 
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•  Application  Objects,  corresponds  to  the  traditional  notion  of  an  application 
and  are  not  standardized  by  OMG.  It  is  important  to  realize  that  classes  that 
fall  into  the  Application  Objects  classification  are  at  the  same  OMA  semantic 
level  as  Common  Facilities  classes.  For  example,  one  can  take  advantage  of 
Object  Services  and/or  Common  Facilities  to  build  his  own  Application 
Object  that  can  be  shared  through  the  network. 

In  general  terms,  the  Application  Objects  and  Common  Facilities  have  an  application 
orientation  while  the  Object  Request  Broker  and  Object  Services  are  concerned  more 
with  the  system  or  infrastructure  aspects  of  distributed  object  management.  The  Object 
Request  Broker  then,  is  the  core  of  the  Reference  Model.  Nevertheless,  an  Object 
Request  Broker  alone  can  not  enable  interoperability  at  the  application  semantic  level.  It 
acts  as  a  telephone  exchange,  which  provides  the  basic  mechanism  for  making  and 
receiving  calls  but  does  not  ensure  meaningful  communication  between  subscribers. 
Object  Services,  Common  Facilities  and  Application  Objects  provide  different  levels  of 
semantics  by  using  an  ORB  as  the  basis  for  communication. 

3.  Structure  of  an  Object  Request  Broker 

As  described  by  OMG:  "The  Object  Request  Broker  provides  the  mechanisms  by 
which  objects  transparently  make  requests  and  receive  responses. 


Figure  2.1  The  ORB  Interconnection  Bus 
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The  ORB  provides  interoperability  between  applications  on  different  machines  in 
heterogeneous  distributed  environment  and  seamlessly  interconnects  multiple  object 
systems" [3].  Thus,  we  can  view  the  ORB  as  an  object  interconnection  bus  through  which 
objects  in  different  machines  can  communicate  with  each  other  to  complete  the 
cooperative  work.  This  is  shown  in  Figure  2.1. 

The  ORB  is  responsible  for  finding,  communicating  with,  and  activating  the 
object  server.  The  structure  of  a  CORBA  Object  Request  Broker  is  given  in  Figure  2.2, 
and  it  is  introduced  in  the  succeeding  subsections: 


Figure  2.2  The  Structure  of  a  CORBA  Object  Request  Broker  [From  Ref.  2] 

B.  APPLICATION  DEVELOPMENT  IN  CORBA 

As  shown  in  Figure  2.3,  CORBA  environment  consists  of  the  following  major 
components:  the  client  object,  the  object  server,  the  IDL  compiler  and  the  ORB.  We 
briefly  describe  the  functionality  of  each  of  these  components  and  then  discuss  the 
interaction  among  these  components  during  the  development  and  the  execution  of  the 
program. 
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In  CORBA,  the  services  of  an  object  are  specified  in  terms  of  an  application 
program  interface  (API)  using  the  standard  CORBA  interface  definition  language  (DDL) 
which  is  machine  and  programming  language  independent.  An  object  that  implements  the 
service  (or  API)  according  to  an  IDL  interface  specification  is  called  an  object 
implementation. 


Figure  2.3  Common  Object  Request  Broker  Architecture 
1.  The  Concept  of  CORBA 


In  another  point  of  view,  an  object  implementation  is  an  executable  entity  that  is 
capable  of  providing  to  the  client,  a  service  declared  by  the  IDL.  A  client  makes  a  request 
to  an  object  implementation  and  expects  the  reply  via  an  ORB.  Here,  the  ORB  serves  as  a 
software  interconnection  bus  between  the  client  and  the  object  implementation.  As  shown 
in  Figure  2.3,  a  client  is  able  to  access  the  services  of  an  object  implementation  only  if  it 
has  a  reference  to  that  object.  This  reference,  called  the  client  stub,  is  generated  by  the 
IDL  compiler  from  the  IDL  specification  of  the  object  server. 
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The  object  implementation  can  provide  its  service  over  the  networks  via  an  ORB 
only  if  it  has  an  implementation  skeleton,  which  is  also  generated  by  the  DDL  compiler. 
Figure  2.4  illustrates  the  complete  development  of  an  object  implementation  and  a  client 
program. 


- ► 


Source  Code 


► 


Code  Generated  by  DDL 


Application  Program 


Figure  2.4  The  Application  Development  in  CORBA 

Corba  provides  a  mapping  between  a  name  and  an  object  reference.  Storing  such 
a  mapping  in  the  ORB  is  known  as  binding  an  object,  and  removing  this  entry  is  called 
unbinding. 
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Obtaining  an  object  reference  which  is  bound  to  a  name  is  known  as  resolving  the 
name.  We  now  briefly  describe  the  basic  concept  of  how  CORBA  and  its  components 
operate.  To  invoke  an  operation  on  a  remote  object  implementation,  a  client  must  first 
bind  to  that  object.  The  ORB  then  checks  if  an  instance  of  the  remote  object 
implementation  exists,  if  not,  an  instance  of  the  object  implementation  will  be  created. 
The  client  can  then  invoke  operations  on  the  remote  object  implementation  by  sending 
requests. 

The  object  implementation  returns  the  results  of  the  invocation  to  the  client  via 
the  ORB  after  it  completes  the  invocation.  Subsequent  invocations  can  be  made  without 
re-establishment  of  the  communication  channel. 

Note  that  DDL  is  a  definition  language,  it  is  not  an  operational  programming 
language  such  as  Java.  Given  an  IDL  interface,  there  may  exist  many  object 
implementations  for  that  interface.  Moreover,  these  object  implementations  may  be 
implemented  in  various  programming  languages  on  different  operating  systems  or 
hardware  platforms.  DDL  compilers  are  used  to  compile  DDL  interfaces,  producing  a 
client  stub  and  and  implementation  skeleton  in  a  specific  target  programming  language 
according  to  CORBA  language  binding  specifications.  IDL  compilers  exist  to  map  IDL 
to  C,  C++,  Java  and  many  other  languages. 

2.  Interface  Definition  Language 

Interface  Definition  Language  (IDL)  is  the  key  to  the  success  of  CORBA,  so  we 
will  take  a  look  at  it  first.  CORBA  1.1,  introduced  in  1991,  defined  the  IDL.  IDL 
provides  a  language  to  define  the  public  interface  for  an  object  that  will  be  accessible 
across  the  ORB,  similar  to  defining  an  object  in  an  object-oriented  language.  The 
interface  of  an  object  consists  of  named  attributes,  operations  and  the  parameters  required 
by  these  operations.  Using  IDL,  an  object  publishes  its  interface  to  the  common 
interconnection  bus  (ORB),  allowing  clients  connected  to  the  bus  know  what  operations 
are  provided  and  how  these  operations  can  be  invoked  across  the  bus.  DDL  is  the  contract 
that  binds  clients  to  server  components. 
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Most  importantly,  an  IDL  interface  is  independent  of  the  programming  language 
that  is  used  to  implement  it.  From  the  client  program’s  point  of  view,  only  the  DDL 
interface  of  a  server  object  is  important,  the  choice  of  implementation  language  is  not.  As 
a  result,  the  client  can  use  the  same  semantics  to  access  different  objects  implemented  by 
different  languages,  through  the  ORB.  As  in  most  object-oriented  languages,  we  also  can 
use  inheritance  to  define  new  IDL  interfaces. 

The  following  is  an  IDL  interface  example  of  a  course  registration  object. 

interface  Register 

{ 

courseSeq  add_course(in  string  course. _index_number,  in  string  Student _ID, 
in  string  password ,  in  string  studentName) 
courseSeq  drop_course(in  string  course_index_number,  in  string  Student. _ID, 
in  string  password ,  in  string  studentName) 

}; 


The  above  interface  provides  two  operations:  add_course  and  drop_course  .  Both  of 
these  operations  have  input  parameters  course _index_number,  Student_ID,  password  and 
studentName . 

3.  ORB  Client 

Now,  let  us  see  how  CORBA  works  on  the  client  side.  As  Figure  2.2  shows, 
CORBA  provides  two  ways  for  clients  to  invoke  services.  The  first  way  is  the  static 
invocation  in  which  client  IDL  stubs(generated  by  the  IDL  compiler)  act  as  proxies  to 
object  implementations.  In  the  context  of  the  client  program,  the  syntax  of  invoking  a 
remote  object  is  the  same  as  invoking  a  local  object.  When  invoking  a  remote  object,  the 
client  requests  are  forwarded  by  the  client  side  stubs  to  the  remote  object  through  the 
ORB. (Figure  2.5)  Sometimes  we  don't  know  the  services  we  want  to  invoke  until  run 
time.  Thus,  it  is  not  possible  to  include  the  IDL  stub  code  in  our  client  code.  In  such  a 
situation,  dynamic  invocation  APIs  can  help  us  discover  a  service  that  we  want  to  invoke 
and  its  definition,  then  we  can  issue  a  request  to  it. 
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Host  1  Host  2 


Figure  2.5  The  Operation  Call  on  a  Proxy 

The  Interface  Repository  makes  dynamic  invocation  possible.  The  Interface 
Repository  maintains  full  information  about  interface  and  type  definitions  of  the  IDL 
definitions  and  provides  this  information  at  run  time.  Given  an  object  reference,  we  can 
obtain  the  interface  and  all  the  information  about  the  interface  at  runtime  by  calling 
Interface  Repository’s  API’s. 

4.  Object  Implementation 

ORB  servers,  also  called  object  implementations  to  distinguish  them  from  the 
interface  of  objects,  provide  the  actual  state  and  behavior  of  an  object.  The  ORB  core 
(Figure  2.2)  locates  an  object  adapter  and  forwards  requests  to  the  object 
implementations  through  the  skeletons.  The  skeletons  are  the  server  DDL  stubs  that 
implement  the  services  that  the  object  exports.  In  addition,  CORBA  2.0  also  introduces 
dynamic  skeleton  to  provide  a  run-time  binding  mechanism  for  server  objects. 

The  object  adapter  makes  use  of  the  ORB's  core  communication  services  to 
accept  requests  on  behalf  of  server  objects.  It  provides  the  run-time  environment  to 
activate  server  objects,  pass  requests  to  them,  assign  them  an  object  reference  and  ensure 
the  security  of  interactions.  It  also  records  the  classes  it  supports  and  their  run-time 
instances  in  the  Implementation  Repository.  (Figure  2.2) 
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The  Implementation  Repository  maintains  information  that  allows  an  ORB  to 
locate  and  activate  implementations  of  objects.  Therefore,  the  server  programmers  must 
register  their  code  with  to  the  Implementation  Repository. 

5.  ORB  and  RPC 

Anyone  experienced  with  writing  client/server  applications  using  RPC  (Remote 
Procedure  Call),  will  find  that  the  mechanisms  of  an  ORB  and  RPC  are  somewhat 
similar.  Both  must  specify  the  interface  first  (object  and  its  methods  in  ORB,  but  remote 
procedure  names  in  RPC),  use  a  compiler  to  generate  both  client  and  server  stubs,  then 
link  the  stubs  with  your  client/server  programs.  However,  there  are  some  significant 
differences  between  ORB  and  RPC.  With  RPC,  we  call  a  specific  function  by  its  name 
and  the  data  is  separate  from  the  function.  In  contrast,  with  the  ORB  we  can  invoke  a 
method  within  a  specific  object  which  manipulates  its  own  private  data.  The  advantages 
of  ORB  over  RPC  are  basically  the  same  as  the  advantages  of  object-oriented  over 
procedural  programming  language.  Furthermore,  CORBA  provides  not  only  the 
communication  mechanism  between  clients  and  servers,  but  also  a  complete  environment 
to  create  portable  and  interoperable  client/server  applications. 

6.  Programming  Environment 

This  thesis  was  developed  on  the  JavaORB  for  Windows  NT  4.0  operating  system 
with  the  JavaORB  compiler.  This  environment  was  selected  for  the  following  reasons: 
First,  Java  is  a  mature  and  stable  product.  Second,  Java  IDL  supports  CORBA  2.0 
features  which  has  a  formal  specification  with  IDL  to  Java  mapping.  Finally,  Windows 
NT  is  more  accessible  than  UNIX  workstations  and  higher  reliability  than  DOS/Windows 
3.1/Windows  95.  For  cost  consideration  and  future  expansion,  we  chose  Windows  NT 
instead  of  UNIX. 
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III. 


SYSTEM  OVERVIEW 


This  chapter  introduces  the  transaction  concept  and  describes  a  global  view  of  our 
Object  Transaction  Service  (OTS).  The  OTS  is  treated  as  a  "black  box"  here,  and  the 
components  that  cooperate  to  provide  the  transaction  service  will  be  explored  in  the  next 
chapter.  We  focus  our  attention  on  the  relationship  between  transactional  clients,  servers 
and  the  transaction  service.  OTS  operates  as  a  transaction  manager.  Moreover,  OTS  also 
provides  a  mechanism  to  allow  the  participants  to  cooperate  with  the  transaction  manager 
to  complete  their  work. 

A.  TRANSACTION  DEFINITION 

OTS  provides  transaction  synchronization  across  the  elements  of  a  distributed 
client-server  application.  In  a  typical  scenario,  a  client  initiates  a  transaction  and  then 
issues  requests.  Eventually,  the  client  decides  to  end  the  transaction.  If  there  are  no 
failures,  changes  are  committed;  otherwise,  changes  are  rolled  back. 

B.  TRANSACTION  PROPERTIES 

As  introduced  in  chapter  one,  the  transaction  concept  is  essential  for  building  reliable 
distributed  applications.  We  define  a  transaction  as  a  unit  of  work,  which  comprises 
several  operations  made  on  one  or  more  shared  system  resources  that  are  governed  by 
ACID  properties,  where  ACID  stands  for  the  Atomicity,  Consistency,  Isolation,  and 
Durability  properties  of  a  transaction.  A  unit  of  work  can  be  transactional  only  if  it 
satisfies  these  properties.  Transactions  are  sequences  of  operations  that  are  clustered 
together. 

1.  Atomicity  Property 

The  Atomicity  property  of  a  transaction  requires  that  this  cluster  is  either 
performed  completely,  i.e.  every  single  operation  belonging  to  the  transaction  is 
successfully  executed,  or  not  at  all.  There  is  no  partial  execution  of  the  transaction.  Let  us 
consider  the  example  of  the  course  registration  and  assume  that  we  perform  it  as  a 
transaction. 
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Atomicity  states  that  either  both  the  adding  and  dropping  course  operation  are 
executed  together  (meaning  that  the  course  is  being  successfully  added  to  the  Registrated 
Course  Table)  or  none  of  the  operation  is  performed  (meaning  that  the  course  is  left 
where  it  was).  A  state  in  which  a  course  is  lost  cannot  occur.  The  start  of  a  transaction 
denotes  a  state  to  which  the  transaction  rolls  back  if  any  of  its  operations  fails.  If  the 
transaction  is  completed  successfully,  the  end  of  the  transaction  (which  is  usually  the  start 
of  the  next  transaction)  marks  the  next  valid  state. 

2.  Consistency  Property 

The  Consistency  property  of  a  transaction  requires  that  the  sequence  of 
operations  leave  the  set  of  shared  resources  in  a  consistent  state  at  the  end  of  the 
transaction.  This  does  not  imply  that  states  of  inconsistency  never  occur,  but  their 
occurrence  is  confined  to  within  a  transaction.  As  such,  inconsistent  states  are  hidden  for 
concurrent  transactions  and  they  must  be  resolved  before  the  transaction  is  completed. 

Revisiting  the  example  of  the  course  registration,  a  consistency  constraint  would 
be  that  a  course  is  not  lost.  This  is  true  at  the  end  of  the  transaction  when  the  course  that 
has  been  copied  from  one  table  to  the  other  by  adding  the  name  of  the  student.  Within  the 
transaction,  after  the  adding  has  been  completed  but  before  the  dropping  has  taken  place, 
the  set  of  account  objects  are  in  an  inconsistent  state  as  the  course  iteration  is  not 
complete.  Hence  it  is  the  application  that  defines  the  notion  of  consistency  and  it  is  also 
the  application  that  is  in  charge  of  ensuring  consistency  maintenance.  If  the  transaction 
has  reached  a  certain  state  of  inconsistency  that  cannot  be  resolved,  it  can  abort  itself  and 
recover  to  the  consistent  state  from  which  it  started.  Considering  our  course  registration 
example  again,  if  the  course  has  been  added  to  Registered  Course  table  but  the  other 
course  is  not  dropped,  the  transaction  can  abort  and  the  transaction  mechanism  will 
rollback  to  the  previous  valid  state. 
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3.  Isolation  Property 

The  Isolation  property  of  a  transaction  requires  that  the  sequence  of  operations  is 
performed  in  isolation  from  any  concurrent  transaction  or  unprotected  activity.  This 
means  also,  that  any  modifications  that  a  transaction  makes  are  not  visible  to  other 
resources  before  the  end  of  the  transaction. 

In  this  way  other  transactions  or  unprotected  activities  can  never  see  an 
inconsistent  state  that  may  arise  within  a  transaction.  Likewise,  operations  performed 
within  a  transaction  can  never  access  modifications  of  other  concurrent  transactions. 

4.  Durability  Property 

The  Durability  property  requires  the  effect  of  a  transaction  to  be  persistent  so  that 
it  cannot  be  affected  by  failures.  This  requires  a  copy  of  all  modified  resources  or  a 
representation  of  the  modifications  (a  change  log)  on  persistent  storage.  This  persistent 
representation  can  be  consulted  after  a  failure  to  recover  to  the  state  of  the  last  successful 
transaction.  In  the  case  of  a  transaction  between  two  register  objects  a  transaction 
manager  would  either  update  a  persistent  representation  of  the  two  register  objects  at  the 
end  of  the  transaction,  or  it  would  add  representations  of  the  operation  executions,  i.e.  the 
drop  and  the  add  operation  with  the  actual  parameter  values,  to  a  persistent  log.  Although 
hard  disks  are  most  commonly  used  to  achieve  persistent  storage,  this  need  not 
necessarily  be  the  case.  It  could  also  be  a  battery-backed  or  an  erasable  PROM.  A 
transaction  can  either  terminate  normally,  or  when  some  errors  occur.  When  all  the 
transactional  operations  can  be  performed  successfully,  the  transaction  commits  and  all 
the  updates  will  be  stored  in  the  persistent  storage.  If  any  error  occurs  during  the 
transaction  processing,  the  transaction  roll  backs,  that  is,  it  terminates  without  any  update 
to  the  data  involved  in  the  transaction.  We  observe  that  in  order  to  support  the 
requirement  for  atomicity,  the  data  involved  in  a  transaction  must  be  recoverable.  When  a 
server  object  fails  unexpectedly  due  to  some  hardware  or  software  errors,  the  server  must 
have  the  ability  to  recover  itself  from  the  persistent  storage  to  retain  the  all-or-nothing 
property. 
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Transactions  also  can  be  nested.  A  nested  transaction  allows  programs  to 
have  transactions  embedded  in  existing  transactions.  Nested  transactions  have  the 
advantage  of  providing  finer  granularity  of  recovery  than  flat  transactions,  but  also 
require  additional  controls  to  transaction  processing. 

In  our  transaction  service,  objects  involved  in  a  transaction  can  play  one  of  three 
roles:  the  transactional  client,  transactional  server  or  recoverable  server.  We  will 
examine  each  of  these  in  the  following  sections. 

C.  TRANSACTIONAL  CLIENT 

A  transactional  client  (TC),  also  called  a  transaction  originator,  is  a  process  that  begins  a 
transaction(Figure  3.1).  A  transactional  client  first  binds  to  OTS  (Object  Transaction 
Service)  by  means  of  ORB,  and  issues  a  begin  call  to  OTS  to  create  a  new  transaction 
context  associated  with  the  client  program.  Normally,  the  client  then  issues  a  set  of 
transactional  operations  to  several  transactional  objects  which  contain  recoverable  states. 
Recoverable,  meaning  that  the  objects  participating  in  the  transaction  must  provide 
uniform  facilities  that  can  cooperate  with  OTS  to  maintain  the  transaction  properties 
described  in  section  3.B.  Each  transactional  operation  invoked  on  the  target  objects  will 
be  explicitly  associated  with  a  transaction  context  shared  by  all  participants  of  the 
transaction. 

The  transactional  client  is  oblivious  to  all  the  processing  between  OTS  and  server  objects. 
It  just  begins  a  transaction  and  sends  transactional  requests  to  server  objects,  then 
commits  or  roll  back  the  transaction. 

D.  TRANSACTIONAL  SERVER 

A  transactional  object  is  an  object  whose  behavior  is  influenced  by  being  invoked 

within  the  scope  of  a  transaction.  It  is  not  necessary  that  all  methods  of  a  transactional 

object  be  transactional.  A  transactional  object  can  provide  both  transactional  and 

nontransactional  operations.  In  contrast,  an  object  that  contains  no  transactional  methods 

is  a  nontransactional  object.  Typically,  a  transactional  object  contains  or  indirectly  refers 

to  persistent  data  that  can  be  modified  by  requests. 
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Figure  3.1  Object  Transaction  Service  Overview 

The  Transaction  Object  receives  requests  for  transactional  operations  from  the 
Transactional  Client  and  these  requests  may  be  forwarded  to  the  Recoverable  Objects  or 
be  performed  by  the  Transactional  Object  itself. 

The  transactional  server  (Figure  3.1)  is  a  collection  of  objects  that  are  influenced 
by  a  transaction  but  has  no  recoverable  states  of  its  own.  A  transactional  server 
propagates  the  transaction  context  to  recoverable  objects  whose  methods  are  invoked. 
In  a  real  application,  the  transactional  server  may  not  exist.  It  is  common  for  the 
recoverable  server  (Section  3.D)  to  be  directly  involved  in  the  transaction  and  manage  its 
own  persistent  data. 
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E.  RECOVERABLE  SERVER 

A  recoverable  object  contains  persistent  data  and  these  data  will  be  modified 
within  a  transaction.  We  can  infer  from  the  definition  that  a  recoverable  object  is  also  a 
transactional  object.  The  recoverable  server  (Figure  3.1)  is  a  collection  of  objects  and  at 
least  one  of  which  is  recoverable. 

To  participate  in  the  completion  of  a  transaction,  a  recoverable  object  has  the 
responsibility  for  implementing  some  functions  defined  by  OTS.  With  the  help  of  these 
functions,  an  object  can  cooperate  with  OTS  to  ensure  all  participants  have  the  same 
outcome(commit  or  rollback)  and  can  recover  themselves  in  the  event  of  a  failure.  When 
recoverable  servers  are  invoked  by  a  transactional  client  for  the  first  time,  they  will 
register  themselves  with  OTS  to  become  participants  of  the  transactions.  At  the  end  of  the 
transaction,  recoverable  objects  are  also  involved  in  the  two-phase  commit  protocol 
coordinated  by  OTS.  During  the  processing  of  the  transaction,  recoverable  objects  must 
store  certain  information  in  the  persistent  storage  at  critical  times.  As  a  result,  when  a 
recoverable  server  restarts  after  a  failure,  it  can  recover  its  state  and  participate  in  a 
recovery  protocol  to  complete  the  transaction. 

OTS  provides  an  architected  set  of  EDL-ized  interfaces  for  the  objects  that  make 
up  the  transaction.  The  principal  OTS  module  is  defined  to  be  CosTransactions,  inside  of 
which  are  defined  nine  key  interfaces.  In  addition,  for  interoperability  purposes,  the 
OMG  specified  the  CosTSPortability  module  separately. 

The  CosTSInteroperation  module  defines  what  is  notionally  referred  to  as  a 
transaction  context,  a  way  for  the  OTS  to  keep  track  of  the  state  of  a  particular  part  or 
thread  of  a  transaction.  This  context  contains  the  in-depth  knowledge  about  what  has 
transpired  so  far  in  a  particular  thread  (in  a  threaded  environment)  or  part  of  a  transaction. 

This  is  part  of  the  mechanism  used  by  CORBA  transactional  systems  to  impart 
the  ACID  properties  that  are  the  hallmark  of  a  transaction.  These  objects  cooperate  to 
guide  the  principles  of  transaction  processing.  In  addition  to  methods  that  manipulate 
their  own  data,  the  recoverable  servers,  by  inheriting  some  of  these  interfaces,  provide 
functions  to  participate  in  the  transaction  completion  protocol. 


24 


F.  OTS  MANAGER 

The  OTS  manager  is  the  core  of  the  object  transaction  service.  It  plays  the  role  of 
coordinator  among  the  transaction  participants.  In  other  words,  the  OTS  manager 
cooperates  with  transaction  participants  to  preserve  the  ACID  properties  during  the 
execution  of  a  transaction.  OTS  manager  is  composed  of  the  following  functional 
components:  Current ,  TransactionObject,  TransactionFactory,  Resource,  Control, 
Terminator,  Coordinator  and  RecoveryCoordinator.  These  components  are  specified 
with  IDL  through  which  other  objects  may  access  their  services  via  ORB  (see  Appendix 
A).  The  functionality  of  each  of  these  components  is  illustrated  via  the  following 
example.  Figure  3-2  depicts  the  scenario  that  a  TC  cooperates  with  various  functional 
components  of  the  OTS  manager  to  complete  a  transaction. 


Figure  3.2.  The  Functional  Diagram  of  the  Applications  and  the  OTS  Manager 
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1.  The  transaction  originator  begins  a  new  transaction  by  issuing  a  request  to  the 
Current  object,  and  a  unique  Control  object  is  returned. 


org.omg.  CORBA.  Object  obj  = 

orb.  resolve _initialjreferences(  "TransactionCurrent"); 

org.omg.  CosTransactions.  Current  current  = 

org.omg.CosTransactions.CurrentHelper.narrow(  obj ); 

Control  control  =  current. get_control(); 

2.  Through  the  Control  object,  the  client  can  connect  to  Coordinator  in  order  to  use 
transactional  services. 

Coordinator  coordinator  =  control,  get _coordinator(); 

3.  The  transaction  originator  then  begins  to  invoke  operations  on  the  recoverable 
objects  providing  the  Coordinator  as  an  input  parameter.  Registerjresource 
operation  registers  the  specified  resource  as  a  participant  in  the  transaction 
associated  with  the  target  object.  When  the  transaction  is  terminated,  the  resource 
will  receive  requests  to  commit  or  rollback  the  updates  performed  as  part  of  the 
transaction.  These  requests  are  described  in  the  description  of  the  Resource 
interface. 

RecoveryCoordinator  recCoordinator  =  coordinator. register _resource(r ); 

4.  Recoverable  objects  will  register  their  Resource  objects  with  the  Coordinator  the 
first  time  they  are  invoked  within  the  transaction. 

myResource  r  =  new  myResource(); 

orb.connect(  r ); 

5.  The  client  uses  the  Control  object  to  get  the  Terminator  object  to  end  the 
transaction. 

cu  rrent.  begin(); 

current.commit();  or  current. rollback(); 


The  Coordinator  will  coordinate  the  termination  process  among  Resource  objects 
using  a  proper  commit  protocol. 

coordinator.  rollback_only( ); 
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G.  TRANSACTION  MODELS 

The  Transaction  Service  supports  two  distributed  transaction  models:  flat 
transactions  and  nested  transactions.  A  flat  transaction  is  a  transaction  that  cannot  have 
child  transactions.  Nested  transactions,  on  the  other  hand,  allow  subtransactions 
embedded  within  the  current  transaction. 

Nested  transactions  provide  a  finer  granularity  of  recovery  than  flat  transactions. 
That  is,  when  one  of  the  subtransactions  of  a  parent  transaction  fails,  only  the 
subtransaction  is  rolled  back.  The  parent  transaction  has  the  opportunity  to  correct  or 
compensate  for  the  failure  and  finish  its  work.  Moreover,  subtransactions  can  be  executed 
in  parallel  without  the  risk  of  inconsistent  results. 

A  subtransaction  is  similar  to  a  top-level  transaction  in  that  the  changes  made  on 
behalf  of  a  subtransaction  are  either  committed  in  their  entirety  or  rolled  back.  However, 
when  a  subtransaction  is  committed,  the  changes  remain  contingent  upon  commitment  of 
all  of  the  transaction^  ancestors.  A  transaction  cannot  commit  unless  all  of  its  children 
are  completed.  When  a  transaction  is  rolled  back,  all  of  its  children  are  rolled  back. 

H.  PROGRAMMING  MODELS 

To  begin,  the  developer  decides  whether  to  use  an  explicit  or  implicit  transaction 
context  propagation  model  when  writing  the  IDL  for  the  CORBA  objects.  In  the  world  of 
OTS,  the  scope  of  a  transaction  is  defined  by  a  transaction  context  that  is  shared  by 
participating  objects.  A  transaction  context  is  created  and  becomes  part  of  the 
environment  of  a  transaction  as  the  transaction  begins.  It  spans  the  domain  of  the 
transaction  by  propagation  among  objects.  In  the  programmer’s  point  of  view, 
propagation  of  transaction  context  in  OTS  can  be  implicit  or  explicit. 

1.  Implicit  Method 

Implicit  propagation  means  that  requests  are  implicitly  associated  with  the  client’s 
transaction;  they  share  the  clients  transaction  context.  The  context  is  transmitted 
implicitly  to  the  objects,  without  direct  client  intervention. 
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Implicit  method  requires  the  application  domain  CORBA  object  interface  to  inherit 
from  the  TransactionalObject  interface.  For  example: 


interface  SI : 

CosTransactionsr.T, ransactionalObject 

{ 

void  opl(  void  ); 

} 

This  method  does  not  require  any  modifications  to  the  operation  signatures,  and 
the  transactional  context  passes  from  point  to  point  in  the  transaction  ‘invisibly’  through 
the  stub  code.  The  inheritance  requirement  indicates  to  the  OTS  that  transaction  context 
information  is  contained  in  any  IIOP  messages  that  is  exchanged  between  clients  and 
servers. 

2.  Explicit  Method 

Explicit  propagation  means  that  an  application  object  propagates  a  transaction 
context  by  passing  objects  defined  by  the  Transaction  Service  as  explicit  parameters. 

Explicit  method  requires  that  any  interface  operations  that  need  to  be 
transactional  have  an  in  parameter  of  type  Control.  In  essence,  this  is  a  way  for  the 
transaction  to  pass  itself  along  from  point  to  point  (or  server  to  server)  in  the  transaction 
because  Control  is  a  sort  of  handle  to  the  transaction  itself.  An  example  would  be: 

interface  SI 

{ 

void  opl(  in  CosTransactions: .'Control  x  ); 

} 
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IV.  SYSTEM  ARCHITECTURE 


In  Chapter  III,  we  treat  Object  Transaction  Service  (OTS)  as  a  “black  box”  and 
focus  on  the  discussion  between  OTS  and  transactional  clients  and  servers.  In  this 
chapter,  we  look  into  the  “black  box”  and  explore  our  system  architecture. 

A.  OVERVIEW 

Object  Transaction  Service  (OTS)  defines  a  set  of  EDL-ized  interfaces  for  objects 
that  make  up  the  transaction  service.  Each  IDL  interface  defines  a  functional  component 
and  OTS  uses  these  components.  Figure  4.1  illustrates  the  system  architecture  of  OTS. 

In  the  general  scenario,  the  transaction  originator  begins  a  new  transaction  by 
issuing  a  request  to  a  TransactionFactory  object  and  a  Control  object  is  returned.  With 
the  methods  provided  by  the  Control  object,  the  transaction  originator  can  get  a 
Terminator  object  and  a  Coordinator  object. 

interface  TransactionFactory  { 

Control  create! in  unsigned  long  time_out); 

}; 

interface  Control  { 

Terminator  get _terminator()  raises  (Unavailable); 

Coordinator  get_coordinator( )  raises  (  Unavailable ); 

}; 


The  transaction  originator  can  use  a  Terminator  object  to  commit  the  transaction  after 
finishing  all  its  transactional  operations  or  rollback  the  transaction  directly. 

The  Coordinator  object  is  made  available  to  the  recoverable  objects  by 
associating  it  with  the  transaction  context  that  is  explicitly  passed  to  recoverable  objects 
as  a  parameter  of  each  transactional  operation.  When  a  recoverable  object  is  invoked 
within  a  transaction  scope  for  the  first  time,  it  registers  a  Resource  object  with  the 
Coordinator  object  to  participate  in  the  transaction. 
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myResource  r  =  new  myResource(); 

orb.connect  (r); 

org. omg.  CosTransactions.  Current  current  =  getCurrent( ); 

Control  control  =  current. get jcontrol(); 

Coordinator  coordinator  =  control  get _coordinator(); 

Recovery  Coordinator  rec  Coordinator  =  coordinator  .register _resource(  r  ); 

A  Resource  object  implements  the  two-phase  commit  protocol  that  is  derived  by 
the  Coordinator  object.  In  some  failure  cases,  a  recoverable  object  can  contact  a 
RecoveryCoordinator  object  to  determine  the  outcome  of  the  transaction  and  complete 
the  transaction  on  its  side.  In  the  next  section,  we  will  take  a  close  look  at  these 
components  that  make  up  OTS. 


Figure  4.1  System  Architecture  of  OTS 
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B.  OBJECT  TRANSACTION  SERVICE  INTERFACES 

We  describe  the  interfaces  of  OTS  in  this  section.  Each  of  these  interfaces  is 
specified  by  Interface  Definition  Language(IDL)  and  represents  a  functional  unit  of  the 
transaction  service.  Each  interface  defines  the  operations  and  parameters  that  are 
exported  to  other  components  of  the  service.  The  OTS  interfaces  specified  by  the  OMG 
are  listed  in  Appendix  A,  and  their  descriptions  also  can  be  found  in  [1].  These  interfaces 
will  be  introduced  by  following  the  programming  logic.  Full  details  of  every  operation 
will  be  presented.  The  transaction  coordinator  as  we  have  introduced  it  above  is  specified 
through  two  interfaces:  Current  and  Coordinator. 

The  Current  interface  specifies  operations  through  which  transactional  clients 
access  transaction  operations  to  start,  commit  or  abort  a  transaction.  The  Coordinator 
interface  specifies  coordination  operations  that  are  used  by  transactional  servers 
(resources  in  the  CORBA  terminology).  Finally,  the  Resource  interface  specifies 
operations  that  are  to  be  provided  by  transactional  servers  in  order  to  implement  the  two- 
phase  commit  protocol. 

1.  Current  Interface 

interface  Current  { 

void  begin()  raises(SubtransactionsUnavaiiable); 

void  commit(in  boolean  report  Jieuristics)  raises  (NoTransaction,  HeuristicMixed, 

HeuristicHazard ); 

void  rollback()  raisesf NoTransaction); 

Status  get_status( ); 

string  get_transaction_name( ); 

void  setjtimeout( in  unsigned  long  seconds); 

Control  get_control( ); 

Control  suspend() ; 

void  resume(in  Control  which)  raises(InvalidControl); 

}; 

Interface  Current  defines  the  operations  that  transactional  clients  use  to 
manipulate  transactions.  Operation  begin  starts  a  new  transaction.  If  a  transaction  has 
been  started  before,  it  starts  a  subtransaction  of  the  previously  started  transaction. 
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Operation  commit  ends  a  (sub)  transaction.  If  the  transaction  is  the  root 
transaction,  all  changes  are  made  durable.  Operation  rollback  reverts  all  resources 
participating  in  the  (sub)transaction  to  the  state  they  had  when  the  transaction  started.  The 
operation  get_control  provides  a  reference  to  the  CORBA  object  that  is  the  transactional 
server's  interface.  Operation  suspend  stops  the  execution  of  a  transaction  (without 
aborting  it).  It  returns  a  reference  to  a  coordinator  which  can  be  used  as  an  argument  to 
the  resume  operation,  which  continues  the  execution  of  that  transaction. 

2.  Coordinator  Interface 

interface  Coordinator  { 

Status  get_status( ); 

Status  get _parent_status(); 

Status  get_top_level_status( ); 

boolean  is_same_transaction(in  Coordinator  tr); 

boolean  is_related_transaction( in  Coordinator  tr); 

RecoveryCoordinator  register _resource( 

in  Resource  r)  raises(Inactive); 
void  register _subtran_aware( 

in  SubtransactionAwareResource  r) 
raises( Inactive,  NotSubtransaction ); 


}; 


This  Interface  presents  an  excerpt  of  the  Coordinator  interface,  which  is  also  part 
of  the  transactional  coordinator  and  is  used  by  transactional  servers.  The  two  most 
important  operations  of  the  coordinator  interface  are  register  jresource  and 
register _subtran_aware.  They  add  a  transactional  server  (i.e.  a  resource)  that  is  passed  as 
an  argument  to  the  set  of  resources  that  participate  in  a  transaction  or  a  subtransaction. 
The  other  operations  can  be  used  by  transactional  servers  to  obtain  status  information 
about  the  transaction,  its  parent  or  the  root  transaction. 
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Resource  Interface 


3. 

interface  Resource  { 

Vote  prepareQ; 

void  rollback()  raises(...); 

void  commit()  raises(...); 

void  commit _one_phase  raises(...); 

void forget(); 

}; 

interface  SubtransactionAwareResource:Resource  { 

void  commit _subtransaction(in  Coordinator  p); 
void  rollback_subtransaction( ); 

}; 

Resources  that  participate  in  flat  transactions  must  be  defined  as  subtypes  of 
Resource  and  those  transactional  servers  that  participate  in  subtransactions  must  be 
subtypes  of  SubtransactionAwareResource.  They  then  have  to  redefine  the  operations 
prepare,  rollback,  commit,  commit _one _phase  and  forget.  In  the  implementation  of  these 
operations,  transactional  servers  would  then  implement  their  part  of  the  two  phase 
commit  protocol. 

C.  CLIENT  AND  SERVERS 

An  IDL  interface  looks  like  the  definition  of  a  C++  class  and  it  indeed  maps  to  an 
actual  Java  class  (certainly,  it  can  be  any  other  object-oriented  language  in  other  CORBA 
implementations).  Every  object  that  wishes  to  be  accessible  across  the  ORB  must  specify 
its  IDL  interface  at  first,  then  an  IDL  compiler  generates  the  mapping  Java  class,  called 
IDL  Java  class,  according  to  the  IDL  interface  in  Figure  4.2,  it  defines  Register  interface. 
An  IDL  Java  class  lists  the  functions  that  clients  of  the  interface  can  invoke,  and  these 
functions  must  be  defined  in  Java  (or  other  object-oriented  language)  by  the  implementer 
of  the  interface.  With  the  help  of  the  IDL  Java  class,  a  client  can  access  the  remote 
implementation  objects  in  the  CORBA  environment. 

A  single  Java  object  can  implement  multiple  interfaces  and  an  IDL  interface  also 
can  have  different  server  objects  to  implement  it  in  different  ways. 
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An  object  server  can  contain  any  number  of  server  objects  that  implement  the 
same  or  different  IDL  interfaces.  An  object  must  register  itself  with  an  ORB  before  any 
client  can  access  it.  A  registered  server  will  be  activated  by  an  ORB  if  it  is  dormant  when 
one  of  its  methods  is  invoked. 


# include  "CosTransactions.  idl " 

module  Projectf 

exception  UnavailableCourse 

{ 

string  course_name; 

}; 

struct  course 

{ 

string  index_number; 
string  course, jcode; 
string  section; 
string  course_name; 
string  meeting; 
string  credits ; 
string  student _ID; 

}; 

typedef  sequence  <  cou  rse  >  cou  rseSeq ; 

interface  Register :  CosTransactions: :TransactionalObject 

{ 

courseSeq  addjcourse(in  string  course  _index_number, 

in  string  Student_ID,  in  string  password , 
in  string  studentName) 
raises  (  UnavailableCourse  ); 

courseSeq  drop_course( in  string  course Jindex_number,  in  string  Student _ID, 

in  string  password,  in  string  studentName) 
raises  (  UnavailableCourse  ); 

}; 

}; 


(a) 
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(IDL  interface) 
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Figure  4.2  (a)  The  Register  IDL  Interface 

(b)  The  Programming  Environment  for  Clients 

1.  Begin  a  Transaction 

Initially,  there  may  be  one  or  more  OTS  servers  available  in  a  distributed 
environment.  Each  of  these  OTS  servers  provides  the  same  Current  object.  A  transaction 
originator  can  choose  any  OTS  server  to  be  the  coordinator  site  of  its  transaction.  A 
transaction  originator  first  binds  to  the  TransactionCurrent  object,  then  invokes  the 
begin( )  operation  of  Current  to  begin  a  new  transaction. 

org.omg.CosTransactions.  Current  current  =  getCurrent(); 
current.  begin(); 


private  org.omg.CosTransactions. Current  getCurrent()  { 

System.err. printing Session:  resolve  transaction  current”); 
try{ 

org.  omg.  CORBA .  Object  obj  = 
orb.  resolve_initial_references( " TransactionCurrent  ”); 
org.omg.CosTransactions.Current  current  = 
org.  omg.  CosT ransactions.  CurrentHelper.  narrow(  obj  ); 


iff  current  =  =  null )  { 

Sy  stem.  err.  println(  "current  is  not  of  expected  type"); 

} 

return  current; 

}//end  of  try  block 

catch(  org.omg.CORBA.ORBPackage.InvalidName  in  ) 

{ 

System.  err.println(  in  ); 
return  null; 

}//end  of  catch  block 
}//end  of  getCurrent()  method 

When  receiving  the  request,  the  Current  object  will  create  a  Control  object  and 
return  a  reference  to  the  Control  object  to  the  client  (Figure  4.3).  The  transaction 
originator  also  can  give  a  time-out  value  to  set  the  maximum  transaction  processing  time. 
If  the  time-out  expires,  the  transaction  will  rollback. 


void  set_timeout( in  unsigned  long  seconds ); 


Figure  4.3  Begin  a  Transaction 

After  creating  the  Control  object  to  control  the  new  transaction,  The  Control 
object  is  associated  with  the  new  transaction  and  responsible  for  the  processing  of  the 
transaction. 
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Transaction  Coordinator 


2. 

When  a  Control  object  is  created,  a  Terminator  object  and  a  Coordinator  object 
are  also  created.  The  Control  object  provides  two  functions: 

Terminator get_terminator()  raises  (Unavailable); 

Coordinator  get_coordinator( )  raises  (Unavailable); 

The  get_terminator()  operation  of  Control  returns  the  object  reference  of  the  Terminator 
object  and  get_coordinator()  operation  Control  returns  the  object  reference  of  the 
Coordinator  object.  A  transaction  can  involve  multiple  objects  performing  multiple 
requests.  All  participating  objects  share  the  same  transaction  context  that  defines  the 
scope  of  the  transaction.  We  must  have  a  mechanism  that  allows  the  objects  involved  in 
the  transaction  service  and  add  related  information  to  the  transaction  context.  A 
Coordinator  object  is  responsible  for  maintaining  the  transaction  context  and  providing 
operations  that  are  used  by  participants  of  the  transaction.  A  transaction  participant,  i.e.,  a 
recoverable  object,  must  issue  a  register _resource()  operation  to  the  Coordinator  object 
when  one  of  its  transactional  operations  is  invoked  by  the  transaction  originator  for  the 
first  time.  Owing  to  we  adopt  implicit  way  to  propagate  the  transaction  context,  just 
because  of  this  reason  I  defined  prepared  a  new  myResourse.java  class;  all  transactional 
operations  of  a  recoverable  object  must  have  an  object  reference  to  the  Coordinator 
object  as  the  last  parameter(Figure  4.4). 

myResource  r  =  new  myResource(); 

orb.connect(  r ); 

Recovery  Coordinator  recCoordinator  =  coordinator,  register _resource(r  ); 


public  class  myResource  extends  org.omg.CosTransactions.^ResourcelmplBase 

implements  org. omg.  CosTransactions. Resource 

l 

public  org. omg.  CosTransactions.  Vote  prepare() 

f 


System. out. println(  "Resource  :  PREPARE”); 

//  We  indicate  that  we  are  OK  to  commit 
return  org.  omg.  CosTransactions.  Vote.  VoteCommit; 
}//end  of  prepare  method 
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/  *  Operation  rollback */ 
public  void  rollback( ){ 

System.out.println(  "Resource :  ROLLBACK"); 

}  //end  of  rollback  method 
/*  Operation  commit  */ 
public  void  commit( ) 

{ 

System.out.println(  "Resource :  COMMIT"); 

)//end  of  commit  method 
/  *  Operation  commit_one _phase  */ 

public  void  commit jone _j>hase( )  { 

System.out.println( "Resource  :  COMMIT jONEJPHASE"); 

}//end  of  commit  jone _phase  method 
/  *  Operation  forget  */ 
public  voidforget() 

{ 

System.  out.println(" Resource  :  FORGET"); 

}//end  of  forget  method 
}//end  of  myResource  class. 


A  Coordinator  object  maintains  a  database  that  records  the  object  references  of 
the  transaction  participants.  When  the  transactional  originator  commits  the  transaction, 
the  Coordinator  object  uses  this  information  to  perform  the  two-phase  commit. 


38 


The  Terminator  object  defines  two  operations  to  end  a  transaction.  Typically, 
these  operations  are  used  by  the  transaction  originator.  The  transaction  originator  issues 
the  commit()  operation  to  mark  the  end  of  the  transaction.  In  some  cases,  a  transaction 
originator  may  wish  to  rollback  the  transaction  it  creates  directly,  then  it  uses  a  rollback() 
operation  to  end  the  transaction.  The  register _resource( )  operation  of  Coordinator 
returns  the  object  reference  of  a  Recovery  Coordinator  to  the  recoverable  object. 

Recovery  Coordinator  recCoordinator  =  coordinator,  register _resource(  this  ); 

In  certain  situations,  a  recoverable  object  can  use  the  replay _completion()  function 
provided  by  RecoveryCoordinator  object  to  drive  the  recovery  process(Figure  4.4). 

3.  Transaction  Participants 

Except  for  their  own  operations,  transaction  participants,  i.e.,  recoverable  objects, 
must  implement  transactional  behavior  to  ensure  the  isolation  and  durability  properties  of 
transactions.  To  complete  a  transaction,  transaction  participants  have  the  responsibilities 
to: 


•  register  themselves  with  the  Coordinator  object  for  transaction  completion; 

•  participate  in  two  phase  commit  protocol;  and 

•  support  transaction  recovery. 

While  registration  was  described  in  Section  4.2.3  and  issues  about  recovery  will  be  left  to 
the  next  chapter,  we  discuss  the  two-phase  commit  protocol  in  this  section. 

The  Object  Transaction  Service  uses  the  two-phase  commit  protocol  to  complete  a 
transaction  with  each  registered  Resource  object.  The  two-phase  commit  protocol  is  a 
well  known  atomic  commit  protocol  and  is  applied  in  many  practical  systems. 

It  is  designed  to  allow  any  recoverable  object  to  abort  its  part  of  a  transaction.  If 
any  part  of  a  transaction  is  aborted,  then  the  whole  transaction  must  be  aborted  for 
atomicity. 
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As  implied  in  the  name,  the  processing  of  the  two-phase  commit  protocol  can  be 
divided  into  two  phases.  In  the  first  phase,  all  recoverable  objects(transaction 
participants)  return  their  votes  for  the  transaction  outcome.  In  the  second  phase,  every 
transaction  participant  carries  out  the  joint  decision. 

It  is  the  transaction  originator  that  issues  commit  (or  rollback)  to  the  transaction  and  the 
request  is  directed  to  the  Coordinator  object.  The  Coordinator  object  then  communicates 
with  the  transaction  participants  to  complete  the  two-phase  commit  protocol.  The 
Resource  object  provides  operations  invoked  by  the  Coordinator  object  on  each 
recoverable  object.  The  communication  of  two-phase  commit  protocol  is  depicted  in 
Figure  4.5. 
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4.  Processing  of  Two-Phase  Commit  Protocol 

The  processing  of  two-phase  commit  protocol  can  be  divided  into  the  following 
four  steps: 

1 .  The  Coordinator  object  invokes  the  prepare( )  method  on  each  recoverable  object. 

2.  When  a  recoverable  object’s  prepareQ  is  invoked,  it  checks  its  own  state  to  see  if 
it  can  commit  its  part  of  the  transaction,  then  replies  its  vote  to  the  Coordinator 
object.  The  vote  can  be  VoteReadOnly,  VoteCommit  or  V oteRollback. 

3.  The  Coordinator  object  collects  the  votes  from  each  recoverable  object,  then  (a) 
If  any  recoverable  object  returns  VoteRollback,  the  Coordinator  object  decides  to 
rollback  the  transaction  and  invokes  the  rollback()  on  all  recoverable  objects 
which  reply  VoteCommit.  (b)  If  at  least  one  recoverable  object  votes  VoteCommit 
and  all  others  vote  VoteCommit  or  VoteReadOnly,  the  Coordinator  object  can 
commit  the  transaction  by  invoking  the  commit()  on  each  of  recoverable  objects, 
(c)  If  all  recoverable  objects  vote  VoteReadOnly,  the  transaction  can  complete 
immediately  and  there  is  no  further  operation  is  required. 

4.  Recoverable  objects  that  vote  VoteCommit  are  waiting  for  a  commit()  or  a 
rollback()  from  the  Coordinator  object.  Each  of  the  recoverable  objects  must 
implement  their  commit  and  rollback  operations,  so  that  they  can  act  accordingly. 

interface  Resource  { 

Vote  preparef ); 

void  rollback()  raisesf...); 

void  commit()  raises  (...); 

void  commit _one _phase()  raises(..); 

voidforget( ); 

}; 


41 


In  the  special  case  of  only  one  participant  registered  for  a  transaction,  the  first 
phase(voting  phase)  is  not  necessary.  Instead  of  issuing  prepare  ()  and  commit()  or 
rollback()  on  the  single  recoverable  object,  the  Coordinator  object  can  invoke 
commit _one _phase(). 
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V.  IMPLEMENTATION  ISSUES 


A.  BACKGROUND  REVIEW 

As  we  have  discussed  in  Chapter  IV,  when  a  transactional  client  begins  a  new 
transaction,  a  set  of  functional  components,  including  Control,  Terminator,  Coordinator 
and  Recovery  Coordinator,  will  be  created  to  play  the  manager  role  of  the  new 
transaction.  OTS  provides  separate  IDL  interfaces  that  define  the  above  components.  The 
benefit  of  dividing  the  transaction  manager  role  into  several  functional  components  is  that 
OTS  can  create  several  different  views  of  the  transaction  manager.  The  transactional 
client  and  recoverable  servers  can  only  access  the  indispensable  part  of  manager 
functions.  For  example,  if  OTS  passes  the  reference  of  a  Coordinator  object  to  the 
recoverable  servers,  then  the  recoverable  servers  have  no  access  to  the  operations  defined 
by  the  Terminator  interface  to  end  the  transaction. 

As  described  before,  an  object  can  implement  multiple  IDL  interfaces  if  it 
provides  all  the  functions  in  these  interfaces.  For  the  convenience  of  implementation,  we 
construct  a  composite  object  to  implement  these  four  interfaces.  But  the  users  still  only 
can  get  the  separate  views  of  the  transaction  manager.  As  shown  in  Figure  5.1,  the  IDL 
compiler  generates  an  IDL  Java  class  for  each  interface  and  Java  ORB  provides 
mechanisms  to  “tie”  the  IDL  Java  class  and  its  object  implementation  together.  The 
programming  environment  hides  the  actual  implementation  from  the  users  (transactional 
client  and  recoverable  servers),  and  creates  separate  views  for  them. 
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Figure  5.1  The  Interfaces  and  Transaction  Manager 


B.  OVERVIEW  OF  THE  EXAMPLE 

This  chapter  describes  the  development  of  distributed,  object-based  transactional 
applications  with  JavaORB  OTS  using  a  sample  Java  application.  At  the  beginning  of 
each  quarter  all  Computer  Science  students  fill  a  course  request  form  for  the  next  quarter 
course  schedule.  The  iteration  scenario  requires  students  to  access  a  remote  database  to 
insert  or  delete  a  class  from  RegisteredjCourse  table.  Students  select  the  Course  from  the 
course  table.  Each  student  accesses  database  by  using  a  Client  program  defined  in  Java.  A 
server  program  controls  access  to  the  database. 

Computer  Science  students  need  to  make  some  transactions  on  this  database. 
Using  Corba  we  can  create  a  distributed,  client  /server,  object-based  transactional 
program. 

What  happens  if  any  error  occurs  during  a  single  user’s  transaction?  For  example, 
attempting  to  register  for  an  invalid  course,  or  attempting  to  drop  a  course  for  which  the 
student  is  not  registered.  How  can  we  turn  back  without  making  any  change  to  database? 
Corba  Object  Transaction  Service  will  handle  this  problem. 
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What  happens  when  two  or  more  users  attempt  to  update  a  RegisteredjCourse 
table  at  the  same  time?  For  this  purpose,  synchronized  methods  and  locks  can  be  used  to 
solve  concurrency  problem. 

During  a  transaction,  a  course  is  transferred  between  the  Course  and  the 
RegisteredjCourse  tables-depending  upon  the  parameters  passed  to  the  client  program. 

The  programs  for  the  Registration  Request  are: 

1.  Registrationlmpl  :  The  Registrationlm.pl  program  takes  input  from  the  Client 
program  via  a  Server  object.  This  program  connects  to  the  database  by  using  JDBC.  As  a 
database  application  this  programs  takes  the  desired  course  from  the  student  and  copies 
this  course  from  the  Core  Course  tables  and  inserts  this  course  in  the  Registered_Course 
table  together  with  the  name  of  the  student.  It  then  begins  a  transaction  and  performs  the 
requested  transfer.  After  all  requested  transfers  have  been  completed,  it  requests  to 
complete  the  transaction  (either  commit  or  rollback).  A  lock  object  is  used  in  both 
synchronized  drop_course  and  add_course  methods  to  lock  these  methods  for 
concurrency  transactions,  also  unlock  function  is  activated  in  commit  or  rollback 
statements. 

2.  Server  :  The  Server  program,  creates  a  Server  object  and  binds  to  a 
Registrationlmpl  object . 

3.  Client  :  The  Client  Program  prepares  the  GUI  to  assist  the  user  student  in 
entering  the  new  course  for  adding  or  for  dropping  an  old  course  from  the  database.  Also 
the  client  program  displays  the  current  course  schedule.  The  client  ensures  that  changes 
made  during  the  transaction  to  courses  are  stored  persistently  (if  committed),  or  that  the 
courses  are  returned  to  their  state  before  the  transaction  (if  rolled  back). 
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Development  and  design  of  a  sample  CORBA  project,  is  discussed  below. 
Unlike  the  other  examples,  this  is  a  more  complete  one  involving  a  GUI  interface  and  a 
backend  database.  JavaORB  from  Distributed  Object  Group  (DOG),  is  used  because  this 
vendor  supplies  a  free  version  of  Corba  Transaction  Service  together  with  CORBA 
architecture. 

C.  A  JAVA -CORBA  SAMPLE 

Here  are  the  steps  to  implement  The  Course  Registration  Program: 

1  .  Implement  a  simple  interface  in  DDL  that  defines  the  Register  object  required  for 
the  Course  Registration  application,  See  "Writing  the  Project  IDL"  in  this  chapter. 

2  .  Implement  the  client  program  and  transaction  originator  (Client):  gather  input  from 
the  user  about  which  course  will  be  added  or  dropped  from  the  database,  initialize  the 
ORB,  get  the  Register  Reference  from  a  file,  narrow  the  object  reference  to  Register 
object,  obtain  a  reference  to  a  transactional  object  (Register)  in  add_course  and 
drop _course  methods,  perform  actions  with  the  transactional  object  (Register),  commit  or 
rollback  the  transaction,  and  handle  exceptions. 

3  .  Implement  the  Server  program:  initialize  the  ORB  and  BOA,  create  and  register  the 
object  then  declare  the  transactional  object,  connect  the  instance  to  the  BOA,  export  the 
object  reference  into  a  file,  then  wait  for  incoming  requests, 

4  .  Implement  the  Registrationlmpi.  this  class  handles  the  database  connectivity  for 
the  server  side,  also  corresponding  to  the  request  of  the  client,  make  add  and  drop 
courses  from  the  tables  under  the  control  of  transaction  rules  defined  by  this  itself, 
performs  actions  with  the  transactional  object  (Register),  commit  or  rollback  the 
transaction,  and  handle  exceptions. 

5  .  Implement  myResource  class:  defines  the  resource  class  operation  that  will  be  used 
myresource  class  used  in  Registrationlmpi  class. 

6  .  Implement  lock  class:  handles  the  lock  and  unlock  function  that  is  used  in  add  and 
drop  course  methods. 
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D.  WRITING  THE  PROJECT  “IDL” 


The  first  step  to  creating  a  transactional  application  with  JavaORB  OTS  is  to 
specify  all  of  our  interfaces  using  the  CORBA  Interface  Definition  language  (DDL).  IDL 
is  language-independent  and  has  a  syntax  similar  to  Java,  but  can  be  mapped  to  a  variety 
of  programming  languages. 


# include  "CosTransactions.idl" 

module  Projectf 

exception  UnavailableCourse 

{ 

string  course__name; 

t; 

struct  course 

{ 

string  index_number ; 
string  coursejcode ; 
string  section; 
string  course _name; 
string  meeting ; 
string  credits; 
string  student_lD; 

}; 

typedef  sequence<course>courseSeq; 

interface  Register :  CosTransactions::TransactionalObject 

{ 

courseS eq  add_course(in  string  course jLndex_number, 
in  string  Student _ID,  in  string  password , 
in  string  studentName) 

raises  (  UnavailableCourse  ); 

courseSeq  drop_course( in  string  course  Jndexjnumber,  in  string  Student _}Dy 
in  string  password ,  in  string  studentName) 
raises  (  UnavailableCourse  ); 

}; 


Figure  5.2  Project  IDL 


DDL  sample  shows  the  contents  of  the  Project.idl  file  which  defines  the  three 
objects  required  for  the  Registration  Course.  Note  that; 
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The  Register  interfaces  inherits  from  CosTransactions::TransactionalObject 
because  this  interface  must  participate  implicitly  in  the  transaction.  If  we  do  not  inherit  it 
from  CosTransactions::TransactionalObject  it  does  not  participate  in  the  transaction. 
Also  note  that  the  IDL  file  must  include  the  CosTransactions.idl  file. 

This  provides  the  IDL  for  the  CosTransactions::TransactionalObject  interface 
from  which  the  transactional  objects  must  inherit.  The  IDL  is  used  by  the  JavaORB’s 
idl2java  compiler  to  generate  Java  stub  routines  for  the  client  program,  and  skeleton  code 
for  the  server  objects.  The  stub  routines  are  used  by  the  client  program  for  all  method 
invocations. 

We  use  the  skeleton  code,  along  with  code  we  write,  to  create  the  server  programs 
that  implement  the  objects.  The  code  for  the  client  and  servers,  once  completed,  is  used 
as  input  to  our  Java  compiler  to  produce  your  client  and  server  programs. 

E.  INTERFACE  DEFINITION  LANGUAGE  (IDL)  TO  JAVA  MAPPING 

When  developing  a  CORBA  application,  the  first  step  is  write  the  IDL  file(s)  for 
the  project.  After  developing  the  IDL,  the  idl2java  compiler  was  used  to  create  the 
necessary  stubs  and  skeletons  for  Java,  so  that  CORBA  clients  can  communicate  with  our 
CORBA  server.  It  should  be  noted  that  the  IDL  is  part  of  the  CORBA  standard;  therefore, 
it  may  be  used  with  any  CORBA  implementation.  IDL  is  used  to  specify  CORBA 
objects,  what  methods  they  have,  what  types  they  return,  etc.  The  example  in  Figure  5.2 
is  an  idl  file  called  Project.idl.  It  defines  one  CORBA  object:  Register.  As  we  can  see  it 
does  not  resemble  Java.  IDL  does  not  provide  implementation  but  the  interfaces  to  the 
object. 

1.  Modules 

An  interface  can  be  defined  within  a  module.  This  allows  interfaces  and  other  IDL-type 
definitions  to  be  grouped  together  in  a  useful  fashion.  Modules  also  create  naming  scope. 
This  means  that  a  type  name  used  in  one  module,  will  not  conflict  with  the  same  name 
used  in  another  module.  The  idl2java  compiler,  maps  modules  to  Java  packages. 
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2.  Interfaces 

An  IDL  interface  provides  a  description  of  the  functionality  that  will  be  provided 
by  a  CORB  A  object.  An  interface  provides  all  the  information  needed  to  develop  a  client 
that  can  use  this  defined  interface  to  interact  with  the  object.  In  the  above  Project.IDL  we 
have  the  Register  interface.  In  an  interface  you  typically  declare:  constants,  types, 
exceptions,  attributes,  and  operations. 

3.  Exceptions 

The  standard  way  of  processing  errors  in  CORBA  is  through  exceptions.  An  DDL 
operation  may  raise  an  exception  indicating  that  an  error  has  occurred.  There  is  an 
example  of  an  exception  in  Figure  5.2.  This  example  shows  that  an  exception 
UnavailableCourse  is  raised  when  the  course  code  that  was  set  is  invalid.  In  addition 
to  supporting  customized  exceptions,  CORBA  defines  a  set  of  standard  exceptions. 

4.  Structures 

A  struct  data  type  allows  related  items  to  be  grouped  together  in  a  useful  fashion. 
An  DDL  struct  maps  to  a  final  Java  class  that  contains  one  instance  variable  for  each 
structure  field.  The  class  name  is  the  same  as  the  DDL  structure  name. 

5.  Sequences 

A  sequence  is  a  one  dimensional  array  with  two  characteristics:  A  maximum  size 
(which  is  fixed  at  compile  time)  and  a  maximum  length  (which  is  determined  at  run¬ 
time).  A  sequence  is  similar  to  a  one  dimensional  array  but  it  is  not  fixed  length. 

Example: 

typedef  sequence<long>  myUnboundedArray', 

or  you  can  have  a  bounded  sequence: 

typedef  sequence<long,  10>  myBoundedArray; 
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6.  Strings 

The  string  type  is  implemented  in  a  way  similar  to  a  sequence  of  char,  which  may 
be  bounded  or  unbounded.  Below  is  an  example: 

interface  library 

{ 

//Bounded  string 
attribute  string  my  string  <12> 

//Unbounded  string 
attribute  string  title 

} 

7.  CORBA  Parameters 

Corba  defines  three  parameter  passing  modes:  in,  out  and  inout.  In  parameters 
pass  from  client  to  server,  out  parameters  pass  from  server  to  client,  and  inout 
parameters  pass  from  both  directions. 

F.  WRITING  THE  TRANSACTION  ORIGINATOR  (CLIENT  PROGRAM) 

The  file  named  Client.java  contains  the  implementation  of  the  Java  client  program 
that  is  also  the  transaction  originator.  The  Client  program  gathers  input  from  the  user  and 
performs  a  single  OTS-managed  transaction 
The  Client  program  performs  these  steps: 

1 .  Initializes  the  ORB. 

2.  CosTransactions  Service  initialization 

3  .  Get  the  Transactional  server  reference  from  an  object  file. 

4.  Narrow  the  object  reference. 

5  .  Get  the  current  object  and  Begin  a  transaction, 
a.  Obtains  a  reference  to  the  transactional  objects 

6.  Invokes  the  add_course()  and  drop_course()  methods  on  the  Registerlmpl  class 
objects  for  each  course  entered  into  to  the  client  program.  It  prints  out  the  current  Course 
Schedule  for  each  Student  after  the  transaction. 

7.  Commits  or  rolls  back  the  transaction. 
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1.  Initializing  the  ORB 

The  first  task  the  transaction  originator  needs  to  do  is  initialize  the  ORB,  as  shown 
in  Code  sample  5.1.  The  parameters  args  and  null  must  be  passed  to  the  ORB,  the  BOA, 
and  the  OTS  Transaction  Service  instance. 

Code  sample  5.1  Example  of  Initializing  the  ORB  with  Java 


public  static  void  main( String [ ]  args)  throws  Exception 
{ 

org.omg.CORBA.ORB  orb  =  org.omg.CORBA.  ORB.  init( args,  null); 


2.  CosTransactions  Service  Initialization 

The  second  task  the  transaction  originator  needs  to  do  is  initialize  the 
CosTransactions,  as  shown  in  Code  sample  5.2.  The  parameter  orb  must  be  passed  to  the 
Boot.init()  method. 

Code  sample  5.2  Example  of  initializing  the  CosTransactions  Service 


public  static  void  main( String []  args)  throws  Exception 
{ 

org.omg.CORBA.ORB  orb  =  org.omg.CORBA.ORB.init(args,  null); 
org.omg.CosTransactions.Boot.init(  orb  ); 

3.  Get  the  Transactional  Server  Reference  from  an  Object  File 

The  third  task  the  transaction  originator  needs  to  do  is  get  the  Transactional  server 
reference  from  an  object  file  ,  as  shown  in  Code  sample  5.3.  The  client  application  is  very 
simple,  to  get  Transactional  server  reference  we  use  a  file  “  Objectld  “  to  which  the 
Server  will  write  its  reference. 
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Code  sample  5.3  Get  the  Transactional  Server  Reference  from  an  Object  File 


org.omg.CORBA.Object  obj  -  null ; 

try! 

java.io.FilelnputStream  file  =  new  java.  io.  File  Input  Stream  ("Objectld"); 
java.io.DatalnputStream  my  Input  =  new  java.  io.DataInputStream(file); 

String  stringTarget  =  my  Input.  readLine(); 
obj  =  orb.  string _to_object( stringTarget); 

} 

catch  ( java.io.lOException  e  ){ 

System.out.println(" Server  reference  not  available... "); 

System.exit(0); 

} 

4.  Narrow  the  Object  Reference 

The  fourth  task  the  transaction  originator  needs  to  do  is  narrow  the  object 
reference,  as  shown  in  Code  sample  5.4  references  to  remote  objects  in  CORBA  use  a 
helper  class  to  retrieve  a  value  from  that  object.  A  commonly  used  method  is  the  helper 
narrow  method,  which  ensures  the  object  is  cast  correctly. 

Code  sample  5.4  Narrow  the  Object  Reference 


static  Register  orblet  -  null; 
tryf 

java.io.FilelnputStream  file  =  new  java.io.FilelnputStream  ("Objectld"); 
java.io.DatalnputStream  mylnput  =  new  java.io.DatalnputStream(file); 
String  stringTarget  =  my Input.  readLinef); 
obj  =  orb.string_to_object(stringTarget); 

} 

catch  (  java.io.lOException  e  ){ 

System.out.println(  "Server  reference  not  available... "); 

System.exit(0); 

} 

// Narrow  the  object  reference 
orblet  =  RegisterHelper.narrow(obj); 
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5.  Get  the  Current  Object  and  Begin  a  Transaction 

Before  beginning  a  transaction,  you  must  obtain  a  transaction  context.  OTS- 
managed  transactions  are  handled  transparently  to  your  application  with  Current~an 
object  that  maintains  a  unique  transaction  for  each  active  thread.  To  use  an  ITS-managed 
transaction,  you  must  obtain  a  reference  to  this  Current  object.  The  Current  object  is  valid 
for  the  entire  process  under  which  you  create  it,  and  can  be  used  in  any  thread. 

Code  sample  5.5  shows  how  to  obtain  an  OTS-managed  transaction.  First  an 
object  reference  is  obtained  for  the  TransactionCuirent  object  using  the 
resolve_initial_references()  method.  The  Current  object  returned  from  this  method  is 
then  narrowed  to  the  specific  CosTransactions.Current  object  using  the  narrowQ  method. 

Code  sample  5.5  Get  the  Current  Object 


private  org.omg. CosTransactions.Current  getCurrent()  { 

System.err.println("Resolve  TransactionCurrent  to  get  access  to  Current  object.  ”); 
try{ 

org.omg.CORBA.Object  obj  -  orb.resolvejnitialjreferences  (" TransactionCurrent "); 

org.omg.CosTransactions.Current  current  = 

org.  omg.  CosT ransactions.  CurrentHelper.  narrow(  obj  ); 

if[  current  ==  null )  { 

System,  err. printing  current  is  not  of  expected  type "); 

}//end  of  if 
return  current; 

}//end  of  try 

catch  ( java.lang. Exception  e  ) 

l 

System,  err.  println(  e ); 
return  null ; 

}//end  of  catch  block 
}//end  of  getCurrentQ 


To  perform  work  that  is  managed  by  OTS,  you  must  first  begin  a  transaction 
using  the  Current  interface’s  begin()  method.  Only  one  OTS-managed  transaction  can  be 
active  within  a  thread  at  a  time.  Code  sample  5.6  shows  the  transaction  originator 
beginning  an  OTS-managed  transaction. 

Code  sample  5.6  Example  of  Beginning  a  Transaction 

//get  current 

org.omg.  CosTransactions.  Current  current  =  getCurrent(); 

//Begin  a  transaction 

System,  out printing Begin  a  transaction. "); 

current  begin() ; 


6.  Invoking  Methods  on  the  Registerlmpl  class  from  Client  Program 

To  invoke  methods  of  the  Register  Interface,  we  have  to  define  the  object  (orblet) 
by  the  name  of  the  Register  Interface  as  described  in  Code  Sample  5.3.  This  object  is 
used  to  invoke  the  methods  ( add_course( )  and  drop_course()  ).  The  methods  of  the 
Register  Interface  can  be  invoked  If  the  object  of  that  interface  (register)  being  gained  by 
the  help  of  that  Interface(Register).  Code  sample  5.6  shows  the  details  of  invoking  a 
method  of  the  Registerlmpl  class  from  the  Client  side(Transaction  Originator). 
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Code  sample  5.6  Invoking  the  add_course()  and  drop_course()  Methods  on 
the  Registerlmpl  Class 


static  course[]  data  =  new  course[100]; 


public  void  addCourse(){ 
try{ 

//get  current 

org.  omg.  CosTransactions.  Current  current  =  getCurrentQ; 

//Begin  a  transaction 
System.out.println(" Begin  a  transaction.  ”); 
current. beginQ; 

System,  out.  println( addCourseTextField.getText( )); 

String  course  Jndex_number  =  addCourseTextField.getText(); 

String  studentName=  studentNameTextField.getText( ); 
data  =  orblet.addjcourse(course_index_number}  student _ID,  password , 
studentName); 

System.out.println(n  Commit  the  transaction  "); 
currenLcommit(true); 

System.out.println(nThe  transaction  has  been  commited"); 

}//end  of  try 

catch  (  java.  lang.  Exception  e ){ 

System.err.println("No  transaction  -  rollbacks  "-he  ); 
try  { 

System.out.println(" Current  Transaction  is  rolling  back”); 
currentrollback() ; 

}//end  of  try 

catch(  org.omg.CosTransactions.NoTransaction  nt)  { 
System.err.println(,r\nNo  transaction  n  +  nt ); 

System.  exit(  1 ); 

}//end  of  second  catch 
}//end  of  first  catch 

} 
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7.  Committing  or  Rolling  Back  a  Transaction 

Once  a  transaction  has  begun,  it  must  be  committed  or  rolled  back  to  complete  the 
transaction.  If  an  originator  of  an  OTS-managed  transaction  does  not  complete  the 
transaction,  the  OTS  Transaction  Service  will  rollback  the  transaction  after  a  timeout 
period.  However,  it  is  important  to  commit  or  rollback  transactions  so  that  hung 
transactions  do  not  consume  system  resources.  Code  sample  5.6  shows  how  the  client 
program  uses  the  commit  variable  to  decide  whether  to  commit  or  rollback  the 
transaction.  If  the  commit  variable  is  true,  the  transaction  is  committed.  If  the  commit 
variable  is  false,  the  transaction  is  rolled  back.  In  Code  sample  5.6,  the  false  parameter 
sent  to  current.commitO  means  that  heuristics  will  not  be  reported.  Note  that  the  test  for 
whether  to  commit  or  roll  back  is  contained  within  a  finally  clause  of  the  previous  try 
clause.  This  is  to  ensure  that  an  unexpected  exception  does  not  bypass  this  code. 

Code  sample  5.7  Example  of  Committing  or  Rolling  Back  the  Transaction 


boolean  commit  =  false; 

try 

{ 

commit  =  true; 

} 

finally 

{ 

//  Commit  or  roll  back  the  transaction 
if  (commit)  { 

System.out.println(u ***  Committing  transaction 
current.  commit(false); 

} 

else  { 

System.out.println( "***  Rolling  back  transaction  ***"); 
current.  rollback( ); 

1 

} 
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H.  WRITING  THE  SERVER  PROGRAM 


The  Server  program  performs  these  steps  in  the  main  routine: 

1.  Initializes  the  ORB. 

2.  CosTransactions  Service  initialization. 

3.  Initializes  the  object  adaptor(  BOA). 

4.  Declare  the  transactional  object. 

5.  Connect  the  transactional  object  to  BOA. 

6.  Convert  the  transactional  object ‘s  reference  to  string. 

7.  Put  the  transactional  object’s  reference  into  a  file. 

8.  Then  wait  for  incoming  requests  from  the  Clients. 

1.  Initializing  the  ORB  ,  the  CosTransactions  and  the  BOA  in  the  Server 
Program 

Before  instantiating  the  Register  object,  the  main  routine  must  make  three  calls- 
one  to  the  ORB,  the  other  to  the  Basic  Object  Adaptor  (BOA)  and  the  third  to 
CosTransactions.  After  the  ORB  is  initialized  the  CosTransactions  service  is  initialized 
using  the  current  orb  as  a  parameter.The  BOA  is  the  interface  between  the  object 
implementation  and  the  ORB.  The  BOA  allows  your  object  to  notify  the  ORB  when  it  is 
ready  to  accept  client  requests  and  informs  it  when  client  requests  are  received.  The 
programming  details  for  this  explanation  are  given  in  Code  sample  5.8. 

Code  sample  5.8  Initializing  the  ORB,  CosTransactions  and  BOA  in  the 

Server 

public  static  void  main( String  args[])  throws  Exception  { 

//  Initialize  the  ORB 

org.omg.CORBA.ORB  orb  =  org. omg. CORBA. ORB. init( args, null ); 

//  CosTransactions  Service  initialization 
org.  omg.  CosTransactions.  Boot.  init(  orb  ); 

H  Initialize  the  BOA 

org.omg.CORBA.BOA  boa  =  org.omg.CORBA.BOA.init(orb,args); 
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2.  Declare  the  Transactional  Object  and  Connect  it  to  Basic  Object 
Adaptor 

While  explaining  the  Project. idl  in  Figure  5.2,  we  focused  on  the  Register 
interface.  We  pointed  out  that  this  interface  is  a  Transactional  object.  For  this  reason  we 
defined  on  the  server  side  a  new  object  by  using  Registerlmpl  class  (actually  extends 
_RegisterImplBa.se  that  is  also  transactional)  by  sending  orb  object,  to  make  a  direct 
relation  between  Server  class  and  Registerlmpl  class.  Then  we  connect  the  instance  of 
this  object  to  the  basic  object  adapter  that  is  initialized  in  this  server  program  to  make 
connectivity  between  Server  and  Registerlmpl  efficient.  The  programming  details  for  this 
explanation  was  given  details  in  Code  sample  5.9. 


Code  sample  5.9  Declare  the  Transactional  Object  and  Connect  it  to  Basic 
Object  Adaptor 

//  Then  declare  the  transactional  object 
Registrationlmpl  orblet  =  new  Registrationlmpl(orb); 

//  Connect  the  instance  to  BOA 
boa.connect(orblet) ; 


3.  Convert  the  Transactional  Object ‘s  Reference  to  String  and  Convert 
it’s  Reference  to  String 

On  the  client  side  a  file  named  an  “ ObjectID ”  was  used  to  read  the  object 
reference  of  the  Server  side  to  make  a  connection  to  the  client  side  object  reference  via 
the  basic  object  adapter.(Code  sample  5.3)  Next  a  string  reference  for  the  transactional 
Register  Object  is  obtained  and  placed  in  a  “ ObjectID ”  file  to  make  the  client  side 
connectivity  by  the  help  of  basic  object  adaptor.  The  programming  details  for  this 
explanation  was  given  details  in  Code  sample  5.10. 


58 


Code  sample  5.10  Convert  the  transactional  object ‘s  reference  to  string  and 
Convert  it’s  reference  to  string 


//  Export  into  a  file  the  object  reference 
String  reference  =  orb.objectjojstring(orblet); 

//then  put  it  into  a  file 
tryf 

java.io.FileOutputStream file  -  new  javaAo.FileOutputStream(”Objectld” ); 
java.io.PrintStream  pfile  ~  new  java.  io.  Print Stream(file); 
pfile.println(  reference ); 

}//end  of  try 

catch  (  java.  io.  lOException  ex  ){ 

System.outprintln("Unable  to  export  server  reference”); 

}//end  of  catch 

4.  Then  Wait  for  Incoming  Requests  from  the  Clients. 

This  method  tells  the  orb  that  the  implementation  object  has  been  created  and  is 
ready  to  take  requests  from  the  client.  The  programming  details  for  this  explanation  was 
given  details  in  Code  sample  5.11. 

Code  sample  5.11  Wait  for  Incoming  Requests  from  the  Clients.. 

//  Then  wait  for  incoming  requests 

try{ 

System.out.println(”The  server  is  ready..."); 
boa.impl_is_ready(); 

}//end  of  try 
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I.  WRITING  THE  TRANSACTIONAL  OBJECT  (REGISTER) 

There  are  a  few  tasks  to  complete  to  implement  the  transactional  (Register)  object: 

•  Derive  the  Registrationlmpl  class  from  the _ RegisterlmplBase  class. 

•  Implement  the  Register  object  with  implementations  for  the  add_course(...) 
and  drop_course(...)  methods  that  activates  the  Database  Connection. 

1.  Understanding  the  Registrationlmpl  Class  Hierarchy 

The  Registrationlmpl  class  that  was  implemented  is  derived  from  the 
_RegisterImplBase  class  that  was  generated  by  the  idl2java  compiler. The 
_RegisterImplBase  interface  is  in  turn  derived  from  the  TransactionalObject  interface. 
Project  ::  Register  inherits  from  CosTransactions  ::  TransactionalObject  so  that  the 
transaction  context  is  propagated  to  it  automatically  by  the  OTS  Transaction  Service. 

2.  Implementing  the  Registrationlmpl  Object  and  its  Methods 

As  shown  in  Code  sample  5.12,  the  Registrationlmpl  interface  defines  its 
constructor  which  creates  an  Registrationlmpl  object  with  the  lock  and  orb  parameters. 
The  Orb  object  is  created  by  Server  in  it’s  main.  Lock  is  defined  by  another  class  to  allow 
concurrent  access  to  the  methods  of  Registrationlmpl  class.  Resource  object  will  be 
explained  later  in  this  chapter. 

Code  sample  5.12  Constructor  for  the  Account  object 

public  RegistrationImpl(org.omg.CORBA.ORB  orb ) 

{ 

this._orb  —  orb; 
lock  =  new  Lock(); 
ifi  _orb  ==  null )  { 

System.err.println("orb  is  not  of  expected  type"); 

}//end  of  if 

r  =  new  myResource(); 
orb.connect(  r  ); 

}//end  of  Registrationlmpl  constructor. 
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3.  Implementing  Methods  of  the  Registrationlmpl  Object 

The  Registrationlmpl  object  defines  some  useful  functions  that  will  be  used  by 
other  methods  for  simplicity,  these  methods  have  been  created  for  use  by  other 
programmers  to  make  their  program  efficient.  These  methods  may  be  implemented  as 
java  classes  in  future  or  maybe  inserted  into  CosTransactions.jar  file  to  make  the 
programmers  more  efficient. 

As  shown  in  Code  sample  5.13.a,  the  Registrationlmpl  object  implements  a 
markForTransactionBegin  ()  method.  When  invoked,  this  method  starts  a  new 
transaction  by  locking  this  object  until  it  is  unlocked  by  the  markForRollbackQ  or 
markForCommitQ  method.  The  markForTransactionBegin  method  gets  the  current 
object  from  another  user  defined  method  named  getCurrentO- 

A  resource  must  be  registered  with  the  Transaction  Service.  Since  we  have  our 
own  resource  implementation  ( myResource.java ),  we  must  take  care  of  the  registration  of 
the  resource  with  the  transaction  service.  A  Current  object  is  obtained  using  the  CORBA 
bootstrap  mechanism.  From  Current  we  get  the  Control  object,  and  from  it  the 
Coordinator  object.  The  resource  can  then  be  registered  with  the  Coordinator  object. 

Code  sample  5.13.a  Implementation  of  the  markForTransactionBegin 
method 

public  void  markForTransactionBegin(){ 

//This  operation  register  a  resource  and  mark  transaction  to  be  rollbacked  only 
try  { 

//lock  addjzourse 
locLlock() ; 

//get  current 
current  =  getCurrent( ); 

System.out.println(  "start  transaction  "); 
current.  begin(); 
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//get  control  and  coordinator 

String  transName  =  current,  get jtransactionjnamef); 

System.out.println(,,Registrationlmp:name  of  the  transaction  :  "  +  transName); 

org.omg.CosTransactions.Status  currentStatus  =  current,  get _status( ); 

System.out.println("RegistrationImpl:  status  of  the  transaction:  "  + 
currentStatus.  value( )); 

System.err.println(''Registrationlmpl:  get  control"); 

Control  control  =  current. get_control(); 

System.err.println("Registrationlmpl :  get  coordinator"); 
coordinator  =  control,  get jcoordinator(); 

//register  resource 

System.out.println("Registrationlmpl :  register  resource  with  OTS "); 
recCoordinator  =  coordinator,  register jresource(  r  ); 

}//  end  of  try  block 

catch  (  java.lang. Exception  e  ){ 

Sy stem. err. printing markForTransactionBegin  catch  block\n"  +  e); 

} 

}//end  of  markForTransactionBegin  method 

Code  sample  5.13.b  shows  the  implementation  of  markForRollback()  method.  When 
invoked,  this  method  calls  rollback_only()  to  force  the  transaction  originator  to  rollback 
the  transaction. 

Code  sample  5.13.b  Implementation  of  the  markForRollback  method 

public  void  markForRollback(){ 
try  { 

//unlock  add_course 
locLunlock(); 

coordinator.  rollback_only( ); 

}//end  of  try  block 
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catch  (  java  Jang.  Exception  e  ){ 

System.  err.println(  e); 

throw  new  org.omg.CORBA.BAD_PARAM(); 

}//end  of  catch  block 
}//end  ofmarkForRollback( ) 

Code  sample  5.13.C  shows  the  implementation  of  a  markForCommit  ()  method.  When 
invoked,  this  method  calls  commit()  to  force  the  transaction  originator  to  commit  the 
transaction.  This  method  also  unlocks  the  transactional  object. 

Code  sample  5.13.C  Implementation  of  the  markForCommit  method 

public  void  markF orCommit()  { 
try  { 

//unlock  addjcourse 
lock.unlock(); 

org.  omg.  CosTransactions.  Status  currentStatusl  =  current,  get _status( ); 
System.out.println("Registrationlmpl :  status  of  the  transaction :"+ 
currentStatusl.  value( ) ); 
current.commit(  true); 

System.out.println(uTransaction  has  been  Committed "); 
org.omg.CosTransactions.Status  currentStatus3  =  current. get jstatusf); 
System.out.println("RegistrationImpl:  status  of  the  transaction:  "  + 
currentStatus3.  value( ) ); 

}  //end  of  try  block 

catch  (  java  Jang.  Exception  e  )  { 

System,  err.printlnf  e ); 
markF orRollback( ); 

}//end  of  catch  block 
}//end  of  markF orCommit() 

Code  sample  5.13.d  shows  the  implementation  of  a  getCurrent  ()  method.  When  invoked, 
this  method  calls  getCurrent  ()  to  force  the  current  object  be  created  and  transmitted  to 
the  caller. 
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Code  sample  5.13.d  Implementation  of  the  getCurrent  method 

private  or g.omg.CosTransactions. Current  getCurrentf )  { 

System.  err.println(  "Session:  resolve  transaction  current"); 
try  l 

org.omg.CORBA.Object  obj  = 

_orb.  resolve Jnitial_references(  "TransactionCurrent"); 
current  =  org.omg.CosTransactions.CurrentHelper.narrow(  obj  ); 
ifi  current  ==  null )  { 

System,  err. printing current  is  not  of  expected  type"); 

}//end  of  if 
return  current; 

}//end  of  try 

catch  (  java.lang.  Exception  e  )  { 

System,  err .  println(  e  ); 
return  null; 

}//end  of  catch  block 
}//end  of  getCurrent( ) 

4.  Implementing  the  Lock  Object 

In  the  Registration  implementation  a  lock  is  used  to  serialize  the  access  to  the 
object.  As  shown  in  Code  sample  5.14,  the  Registrationlmpl  object  also  implements  a 
lockQ  or  unlockQ  method.  The  lock  is  essentially  a  Boolean  variable,  which  indicates  if 
an  object  is  locked  or  not.  The  lock  method  sets  the  lock  variable  to  true.  If  the  object  is 
already  locked  ,  it  waits  for  a  java  event  notification,  which  is  caused  by  the  unlockQ 
method  using  notifyAllQ.  The  unlockQ  method  also  sets  the  lock  variable  back  to  false. 

Code  sample  5.14  Implementing  the  Lock  Object 

package  transaction.util; 
public  class  Lock  { 

private  boolean  locked; 
public  Lock( )  { 

locked  =  false; 

} 
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} 


synchronized  public  void  lock()  { 
while(locked)  { 
try  { 

this.wait(); 

} 

catch(InterruptedException  e)  { 

} 

} 

locked  =  true; 

} 

synchronized  public  void  unlock()  { 
locked  =  false; 

this.notifyAllO; 

} 
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VI.  CONCLUSIONS 


A.  CORBA  OBJECT  TRANSACTION  SERVICE 

What  is  an  ideal  programming  environment  for  the  application  programmers?  The 
answers  may  be  various  and  dependent  on  the  requirements  of  the  programmers. 
However,  one  thing  is  sure,  that  by  some  software  techniques,  we  can  prevent  some 
programmers  from  “ reinventing  the  wheel ”  repeatedly  in  the  same  domain. 

The  concept  of  transactions  is  not  only  useful  in  database  applications,  but  is  also 
useful  in  building  robust  distributed  mission-critical  applications.  Over  the  years,  it  has 
been  shown  that  distributed  applications  can  be  built  effectively  using  distributed  object 
technology  for  its  strong  support  of  heterogeneous  platforms.  The  Object  Transaction 
Service  (OTS)  specification  advocated  by  OMG’s  CORBA  standard  defines  the 
fundamental  transaction  service  to  support  rapid  development  of  transactional 
applications  in  a  distributed  object  environment.  This  thesis  presents  an  implementation 
of  the  Object  Transaction  Service  (OTS). 

CORBA  defines  a  common  software  interconnection  bus  and  forms  a  basic 
building  block  for  distributed  object  computing.  It  does  really  make  sense  if  we  can 
provide  some  common  object  services  that  programmers  can  integrate  their  own  code 
with  these  services  to  develop  a  mission  critical  client/server  software  easily.  The  OTS  is 
our  first  attempt.  To  support  a  complete  transaction  service,  our  work  can  be  divided  into 
two  parts.  On  one  hand,  we  provide  transaction  factories  that  will  create  a  new 
transaction  coordinator  for  each  transactional  client’s  request.  The  client  contacts  its  own 
transaction  coordinator  to  process  the  transaction.  The  transaction  coordinator  is  based  on 
a  presume  abort  two-phase  commit  protocol  and  it  will  store  certain  information  in  stable 
storage  when  it  makes  the  decision  to  commit  or  rollback  the  transaction.  Thus,  if  some 
failures  occur  after  the  transaction  has  a  consensus  outcome,  the  transaction  will  recover 
later  and  complete  the  remaining  work. 
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On  the  other  hand,  the  implementations  of  the  server  objects  also  have  to  follow 
some  principles,  thus  they  can  act  properly  during  the  transaction  processing.  By  using 
inheritance,  we  also  reduce  the  work  to  implement  transactional  server  objects  and  still 
keep  the  flexibility. 

There  are  still  some  ways  to  improve  our  transaction  service.  We  only  support  the 
flat  transaction  model  now,  and  the  ability  to  handle  the  nested  transaction  model  can  be 
added  to  this  transaction  service  in  the  future.  Another  aspect  of  the  transaction  service 
that  can  be  improved  in  our  next  version  is  the  propagation  of  the  transaction  context.  We 
must  pass  the  transaction  context  explicitly  in  each  transactional  function  now.  This  is  a 
burden  for  the  application  programmer. 

The  OMG  also  has  defined  the  standards  of  other  object  services,  e.g.  the  life- 
cycle  service,  the  persistent  service,  the  event  service,  the  concurrency  service  and  so 
on[2].  By  specifying  these  services,  the  OMG  tries  to  provide  a  way  to  build  custom 
middleware.  In  the  near  future,  application  programmers  may  only  have  to  choose  the 
proper  object  services  and  integrate  them  with  their  own  programs  to  build  robust 
distributed  software  systems. 

B.  JAVA  DATABASE  CONNECTIVITY  TRANSACTION  SUPPORT 

In  the  CORBA  and  Java  -application  model,  access  to  database  can  be 
accomplished  in  much  the  same  manner.  Java,  however,  brings  a  new  variant  into  play, 
Java  Database  Connectivity  (JDBC).  JDBC  is  the  Java  interface  to  the  Standard  Query 
Language  (SQL)  and  is  implemented  in  the  java.sql  package.  Most  database  vendors,  as 
well  as  several  third-party  providers,  sell  JDBC  drivers.  Drivers  are  either  direct,  sitting 
on  top  of  the  database’s  native  interface,  or  ODBC-bridged,  mapped  to  an  ODBC 
implementation  for  a  particular  database. 

The  big  advantage  of  using  JDBC,  of  course,  is  its  inherent  cross-database,  cross¬ 
platform  capability.  This  makes  any  JDBC  program  theoretically  portable  to  dozens  of 
major  SQL  databases  and  platforms  without  any  code  rewrite. 
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It  is  possible  to  use  an  ORB  implementation  to  talk  directly  through  a  database 
native  client  library  or  ODBC,  given  that  the  proper  IDL  definition  exists. 

Transaction  support  is  an  important  element  of  large-scale,  enterprise-wide 
deployments.  In  recent  years,  the  definition  of  a  transaction  has  broadened  from  simple 
database  operations  to  include  operations  against  a  variety  of  network  objects.  In  fact, 
any  group  of  operations  that  acts  together  in  a  logical,  dependent  manner  can  be  viewed 
as  a  transaction.  If  any  one  of  the  object  services  fails,  the  entire  transaction  fails,  and  any 
previous  operations  need  to  be  rolled  back. 

CORBA  and  JDBC  both  provide  transaction  support.  CORBA  services  includes  a 
transaction  service  that  supports  single-  and  two-phase  commit,  rollback,  and  nested 
transactions.  JDBC  has  built-in  transaction  support;  new  database  statements  are 
automatically  committed  after  each  executes  successfully.  Finer-grain  control  for 
multiple  statements  and  rollback  can  be  achieved  by  using  the  JDBC  Connection  object’s 
setTransactionlsolationf  )  method  in  conjunction  with  the  commit(  )  and  rollback(  ) 
methods.  The  JDBC  Connection  object  supports  five  distinct  transaction  levels,  which 
may  be  supported  wholly  or  in  part  by  the  underlying  RDBMS. 

JDBC  is  currently  limited  in  that  it  cannot  manage  transactions  across  multiple 
connections.  For  transaction  support  across  databases  or  object  services,  CORBA’s 
Transaction  Service  can  provide  the  correct  level  of  abstraction. 

Additionally,  there  are  several  restrictions  that  must  be  enforced  to  ensure  that  the 
OTS  Transaction  Service  can  manage  transactions. 

The  complete  list  of  restrictions  is  as  follows: 

•  Only  one  application  server  can  be  involved  in  a  transaction. 

•  Only  one  Resource  may  be  involved  in  a  transaction.  The  JDBC 
DirectConnect  driver  transparently  registers  this.  Resource— the  application 
may  not  register  any  other  Resources  for  the  transaction. 
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•  Applications  must  obtain  a  JDBC  connection  when  required,  and  then  call 
close()  on  that  connection  when  that  particular  unit  of  work  is  completed. 
Since  connections  are  pooled,  calling  close()  on  the  connection  is  inexpensive, 
and  does  not  really  result  in  closing  the  underlying  database  connection. 

•  Since  the  JDBC  connections  are  pooled,  properties  that  are  set  for  connections 
in  a  particular  transaction  will  remain  in  effect  when  the  connections  are 
reused  by  other  transactions. 
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APPENDIX  A:  IDL  DEFINITION  FOR  COSTRANSACTION 


#ifndef  _COS_TRANSACTION_ 

# define  _COSJTRANSACTION_ 

#pragma  prefix  " omg.org" 

module  CosTransactions  { 

enum  Status  { 

StatusActive, 

S ta tusMarkedRol lback , 
Status  Prepared , 
StatusCommitted, 
StatusRolledBack, 

S tatusUnknown , 
StatusNoTransaction 


enum  Vote  { 

VoteCommit, 

VoteRollback, 

VoteReadOnly 


exception 

exception 

exception 

exception 

exception 

exception 

exception 

exception 

exception 

exception 

exception 

exception 

exception 

exception 

exception 


Transact ionRequired  { } ; 
TransactionRolledBack  {}; 
InvalidTranscation  { } ; 
HeuristicRol lback  { } ; 
HeuristicCommit  { } ; 
HeuristicMixed  {}; 
HeuristicHazard  { } ; 

Wr ongTrans action  {}; 
Subtransact ionsUnavailable 
NotSubtransaction  { } ; 
Inactive  {}; 

Not Prepared  {}; 
NoTransaction  { } ; 
InvalidControl  { } ; 
Unavailable  {}; 


U; 


interface 

interface 

interface 

interface 

interface 

interface 

interface 

interface 

interface 


Control ; 

Terminator; 

Coordinator; 

Resource; 

RecoveryCoordinat or ; 
Subtransact ionAwareResource ; 
TransactionFactory; 

Transact ionOb j ect ; 

Current ; 
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interface  Current  { 

void  begin()  raises (SubtransactionsUnavailable) ; 
void  commit  (in  boolean  report__heuristics)  raises 

(NoTransaction,  HeuristicMixed,  HeuristicHazard) ; 
void  rollback ( )  raises (NoTransaction) ; 

Status  get_status ( ) ; 

string  get_transaction_name ( ) ; 

void  set_timeout (in  unsigned  long  seconds); 

Control  get^control ( ) ; 

Control  suspend ( ) ; 

void  resume(in  Control  which)  raises (InvalidControl) ; 

}  ; 

interface  TransactionFactory  { 

Control  create (in  unsigned  long  time_out) ; 

} ; 

interface  Control  { 

Terminator  get_terminator ( )  raises  (Unavailable); 
Coordinator  get_coordinator ( )  raises  (Unavailable); 

} ; 

interface  Terminator  { 

void  commit  (in  boolean  report_heuristics) 

raises (HeuristicMixed, HeuristicHazard) ; 
void  rollbackO; 


} ; 


interface  Coordinator  { 

Status  get_status ( ) ; 

Status  get__parent_status  ( )  ; 

Status  get__top_level_status  ( )  ; 

boolean  is_same_transaction (in  Coordinator  tc) ; 
boolean  is_related_transaction ( in  Coordinator  tc) ; 
boolean  is_ancestor„transaction (in  Coordinator  tc) ; 
bolean  is__descendant_transaction (in  Coordinator  tc) ; 
boolean  is_top_level_transaction ( ) ; 
unsigned  long  hash_transaction ( ) ; 
unsigned  long  hash_top_level_tran  ( )  ; 

RecoveryCoordinator  register_resource ( in  Resource 

r) raises (Inactive) ; 

void  register_subtran_aware (in  SubtransactionAwareResource 

r)  raises (Inactive) ; 
void  rollback__only  ( )  raises  (Inactive); 
string  get_transaction_name ( ) ; 

Control  create_subtransaction( )  raises 

(SubtransactionsUnavailable,  Inactive) ; 


} ; 


interface  RecoveryCoordinator  { 

Status  replay_completion (in  Resource  r) 

raises  (NotPrepared) ; 


} ; 
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interface  Resource  { 

Vote  prepare ( ) ; 

void  rollback ()  raises (HeuristicCommit , 

HeuristicMixed, HeuristicHazard)  ; 
void  commit ()  raises  (NotPrepared, 

HeuristicRollback, HeuristicMixed,  HeuristicHazard) ; 
void  commit_one_j?hase  ( )  raises  (HeuristicRollback, 
HeuristicMixed, HeuristicHazard) ; 
void  forgetO; 

} ; 

interface  SubtransactionAwareResource  :  Resource  { 

void  commit_subtransaction(in  Coordinator  parent); 
void  rollback_subtransaction ( ) ; 

Jo¬ 
inter  face  TransactionalObject{ 

} ; 

} ; 


module  CosTSInteroperation 
{ 


struct  otid_t 

{ 

long  format ID; 
long  bequal_length; 
sequence<octet>  tid; 

}; 

struct  Transidentity 
{ 

CosTransactions : :Coordinator  coordinator; 
CosTransactions : : Terminator  terminator; 
otid_t  otid; 

}  ; 

s  t rue  t  Pr opagat i onCon t  ex t 
{ 

unsigned  long  timeout; 

Transidentity  current; 
sequence<TransIdentity>  parents; 
any  implementationjspecific_data; 

}; 

} ; 

#endif 
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APPENDIX  B:  IDL  DEFINITION  FOR  PROJECT 


#include  " CosTransactions . idl " 


module  Project { 


exception  UnavailableCourse 

{ 

string  course_name; 

}; 

struct  course 

{ 

string  index_number; 
string  course_code; 
string  section; 
string  course_name; 
string  meeting; 
string  credits; 
string  student_ID; 

} ; 

typedef  sequence<course>courseSeq; 


} ; 


interface  Register  :  CosTransactions :: Transact ionalObject 

{ 


} ; 


courseSeq  add_course ( in  string  course_index_number ,  in 
string  Student_ID,  in  string  password  , 
in  string  studentName) 
raises  (  UnavailableCourse  ) ; 
courseSeq  drop__course  (in  string  course_index_number , 

in  string  Student^ID,  in  string  password, 
in  string  studentName) 

raises  (  UnavailableCourse  ) ; 
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APPENDIX  C:  SERVER  IMPLEMENTATION 


// - 

//  Filename 
//  Date 
//Subject 
//  Compiler 
// - 


Server . java 
01  Jan  2000 
Master  Thesis 
Sun  JDK1.3 


public  class  Server  { 

public  static  void  main (String  args [] )  throws  Exception  { 
if (  args. length  !=  0)  { 

System,  err  .print  In  ( "java  -DJAVA__ORB_DIR=H :  /  JavaORB/bin/ 
Server  " ) ; 

System. exit (  1  ); 

}//end  of  if 

System. out .print In ( "Starting  the  ORB..."); 

//  Initialize  the  ORB 

org.omg.CORBA.ORB  orb  =  org. omg.CORBA. ORB. init (args, null) ; 

org . omg . CosTransac tions . Boot . init (  orb  ) ; 

//  Initialize  the  BOA 

org . omg . CORBA . BOA  boa  =  org . omg . CORBA . BOA . init ( orb , args ) ; 

//  create  and  register  the  object 
//  Then  declare  the  transactional 

Regis t rat ionlmpl  orblet  =  new  Registrationlmpl (orb) ; 

//  Connect  the  instance  to  BOA 
boa .connect (orblet) ; 

//  Export  into  a  file  the  object  reference 
String  reference  =  orb. object_to_st ring (orblet) ; 

JavaORB .  ut il .  IORManager  ior__manager  =  new 
j  avaORB .util. IORManager { ) ; 

JavaORB. util . IORBag  ior_bag  =  null; 
ior_bag  =  ior_manager .extract (  reference  ); 

System. out .print In ( " " ) ; 

System.out.println("IOR  dump  result"); 

System. out .print In ( " " ) ; 

System. out .print In (" HOP  version  :  "  +  ior_bag. vers ion. major  + 

" . "  +  ior_bag. version. minor  ); 

System,  out.  println(  "Host  name  :  "  +  ior__bag.host  ); 
System.out.println("Port  number  :  "  +  ior_bag.port  ); 

System. out. print In ("Object  id  :  "  +  ior_bag.id  ); 

System,  out  .print  In  ( "Object  key  :  "  +  new  String(  ior_bag.key  )  ); 
System. out .println ( " " ) ; 
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/Vthen  put  it  into  a  file 
try 
{  ' 

java. io . FileOutput St ream  file  =  new 

java.io.FileOutputStream( "Objectld") ; 
java.io.PrintStream  pfile=new  java . io . PrintStream{ file) ; 
pfile.println (reference) ; 

}//end  of  try 

catch  (  java. io.IOExcept ion  ex  ) 

{ 

System. out .println ( "Unable  to  export  server  reference"); 
}//end  of  catch 

//  Then  wait  for  incoming  requests 
try 
{ 

System. out .print In ( "The  server  is  ready..."); 
boa .  impl_jLS_ready  ( )  ; 

}//end  of  try 

catch  (  org.omg.CORBA. SystemException  e  ) 

{ 

System. out .print In ( "An  exception  has  been  intercepted."); 
}//end  of  catch 
}//end  of  main 
}//end  of  server 
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APPENDIX  D:  CLIENT  IMPLEMENTATION 


// - 

//  Filename  :  Client. java 

//  Date  :  01  Jan  2000 

//Subject  :  Master  Thesis 

//  Compiler  :  Sun  JDK1.3 

// - 

import  java. applet .Applet; 

import  j  ava . awt . * ; 

import  java. util.*; 

import  j  ava . awt . event . * ; 

import  j  ava . lang . * ; 

import  j avax . swing .* ; 

import  j  avax . swing . table . * ; 

import  j  avax . swing . event . * ; 

import  j  avax . swing . border . * ; 

import  org . omg . CORBA .* ; 

import  org. omg. CORBA. ORBPackage. *; 

import  org . omg . Pro j  ect . * ; 

import  org . omg . CosTransac tions . * ; 

public  class  Client  implements  LayoutManager 

{ 

static  String!]  ConnectOptionNames  =  {  "Connect"  }; 
static  String  ConnectTitle  =  "Connection  Information"; 

Dimension  origin  =  new  Dimension (0,  0) ; 

JButton  addCourseBut ton ; 

JBut ton  dropCourseBut ton ; 

JButton  showRegisteredCoursesButton; 

JPanel  connect ion Panel ; 

JFrame  frame; 

JLabel  userNameLabel ; 

JTextField  userNameField; 

JLabel  passwordLabel ; 

JTextField  passwordField; 

JComponent  queryAggregate ; 

JPanel  mainPanel; 

JScrollPane  tableAggregate; 

JLabel  courselndexNumberLabell; 

JLabel  courseIndexNumberLabel2  ; 

JLabel  addCourseStudentNameLabel  ; 

DefaultTableModel  dataModel; 

JTextField  addCourseTextField; 

JTextField  dropCourseTextField; 

JTextField  studentNameTextField; 

//Now  get  the  Transactional  server  reference 
static  Register  orblet  ; 
static  String  student_ID  =  null; 
static  String  password  =  null; 

final  String!]  names  =  {"Index  Number",  "Course  Code",  "Section", 

"Course  Name",  "Meeting",  "Credits ", "Student  ID" }; 
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static  course[]  data  =  new  course[100]; 
static  org.omg.CORBA. Object  obj  ; 
static  org . omg . CORBA . ORB  orb; 

org.omg.CosTransact ions .Current  current  =  null; 


public  Client (){ 

mainPanel  =  new  JPanelO; 
for  (int  i=0 ; i<data . length-1 ; i++) { 
data[i]=  new  course (); 
data [ i ] . index_number  =  " " ; 
data [ i ] . course_code  =  " " ; 
data [i] . section  =  " ” ; 
data [ i ] . course_name  =  " " ; 
data [i] .meeting  = 
data [i] .credits  =  ""; 
data[i] .  student„JED  = 

}//  end  of  for 

//  Create  the  panel  for  the  connection  information 
createConnectionDialog( ) ; 

//  Create  the  buttons. 

showRegisteredCoursesButton  =  new  JButton ( "Show  Schedule") 
addCourseButton  =  new  JButton ( "Add  Course"); 
dropCourseButton  =  new  JButton ( "Drop  Course"); 

//Create  the  labels. 

courselndexNumberLabell  =  new  JLabel ( "Course  Index 

Number" ) ; 

courseIndexNumberLabel2  =  new  JLabel ( "Course  Index 

Number" ) ; 

addCourseStudentNameLabel  =  new  JLabel { "Student  Name" ); 
addCourseTextField  =  new  JTextField ( 6 ) ; 
dropCourseTextField  =  new  JTextField ( 6 ) ; 
studentNameTextField  =  new  JTextField ( 16 ) ; 
showRegisteredCoursesButton. addActionListener (new 

QueryChangeListener ( ) ) 
addCourseButton . addActionListener (new 

QueryChangeListener ( ) ) 
dropCourseButton . addActionListener (new 

QueryChangeListener ( ) ) 

//  Create  the  table. 
tableAggregate  =  createTableO; 
tableAggregate . setBorder (new 

BevelBorder (BevelBorder . LOWERED) ) ; 
//  Add  all  the  components  to  the  main  panel. 
mainPanel .add (addCourseButton) ; 
mainPanel . add (dropCourseButton) ; 
mainPanel . add ( showRegisteredCoursesButton) ; 
mainPanel. add (tableAggregate) ; 
mainPanel . add (addCourseTextField) ; 
mainPanel .add (dropCourseTextField) ; 
mainPanel . add ( studentNameTextField) ; 
mainPanel . add (courselndexNumberLabell ) ; 
mainPanel . add ( courseIndexNumberLabel2 ) ; 
mainPanel . add (addCourseStudentNameLabel) ; 
mainPanel . setLayout (this) ; 

//  Create  a  Frame  and  put  the  main  panel  in  it. 
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frame  =  new  JFrame ( "Register  a  Course"); 


frame. addWindowListener (new  WindowAdapter { )  { 

public  void  windowclosing (WindowEvent  e) 

{ 

System. exit (0) ; } 

} 

) ; 

frame . setBackground (Color . lightGray) ; 

frame. getContentPane ( ) . add ( ma inPane 1) ; 

frame.pack()  ; 

frame . setVisible ( false) ; 

frame . setBounds (200 ,  200,  640,  480); 

activateConnectionDialog( ) ; 

}//end  of  client  class 

/** 

*  Brigs  up  a  JDialog  using  JOptionPane  containing  the 

*  connectionPanel .  If  the  user  clicks  on  the 

*  'Connect'  button  the  connection  is  reset. 

*/ 


void  activateConnectionDialogO { 

if (JOptionPane. showOptionDialog (tableAggregate, 
c  onnec  t i onPane 1 , C onne c  t Ti 1 1 e , 

JOptionPane . DEFAULT_0PTI0N, 

JOptionPane . INFORMAT I ON_MES SAGE , null , 
ConnectOptionNames ,  ConnectOptionNames [ 0] )  ==  0) 

{ 

connect ( ) ; 

frame . setVisible (true) ; 

} 

else  if ( ! frame . isVisible ( ) ) 

System. exit (0) ; 


/** 

*  Creates  the  connectionPanel,  which  will  contain  all  the 

*  fields  for  the  connection  information. 

*/ 

public  void  createConnectionDialog( )  { 

//  Create  the  labels  and  text  fields. 

use rNameLabe 1  =  new  JLabel ( "User  name:  ",  JLabel .RIGHT) ; 
userNameField  =  new  JTextField ( " " ) ; 

pa s swordLabe 1  =  new  JLabel ( "Password:  ",  JLabel . RIGHT) ; 
passwordField  =  new  JPasswordField ( " " ) ; 
connectionPanel  =  new  JPanel (false) ; 

connectionPanel . setLayout (new  BoxLayout (connectionPanel , 

BoxLayout . X_ AXIS ) ) ; 
JPanel  namePanel  =  new  JPanel { false) ; 
namePanel . setLayout (new  GridLayout ( 0 ,  1 ) ) ; 
namePanel . add (user NameLabel ) ; 
namePanel . add (pas swordLabe 1 ) ; 

JPanel  fieldPanel  =  new  JPanel (false) ; 
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fieldPanel . setLayout (new  GridLayout (0,  1) ) ; 

*■  fieldPanel . add (userNameField) ; 
fieldPanel .add (passwordField) ; 

connectionPanel .add (name Panel) ; 
connect ionPanel .add (fieldPanel) ; 

}//end  of  createConnectionDialog  method 

class  ShowConnectionlnfoListener  implements  ActionListener  { 
public  void  actionPerf ormed (ActionEvent  e)  { 
activateConnectionDialog{ ) ; 

}//end  of  actionPerf ormed  method 
}//end  of  ShowConnectionlnfoListener  method 

class  QueryChangeListener  implements  ActionListener  { 
public  void  actionPerf ormed (ActionEvent  e) 

{ 

String  c  =  e . getActionCommand ( ) ; 
if  ( c. equals ( "Add  Course" ) )  { 
addCourse ( ) ; 

}//end  of  if 

else  if  (c . equals ( "Drop  Course") ){ 
dropCourse ( )  ; 

}//end  of  else  if 

else  if  (c . equals ( "Show  Schedule"))  { 
displaySchedule ( ) ; 

}//end  of  else  if 
}//end  of  actionPerf ormed  method 
}//end  of  QueryChangeListener  class 

public  void  connect ( ) { 

student_ID  =  userNameField. getText () ; 
password  =  passwordField. getText () ; 

}//end  of  connect  method 

public  void  addCourse () { 
try  { 

//  get  current 

org.omg.CosTransact ions. Current  current  = 
getCurrent ( ) ; 

//  Begin  a  transaction 

System. out .println{ "Begin  a  transaction."); 
current . begin (); 

System. out .print In (addCourseTextField. getText () ) ; 
data  =  orblet . add_course 

(addCourseTextField. getText ( ) ,student_ID, 

password, 

studentNameTextField. getText ()); 

System. out .print In ("!!!! "  +  data [ 0] . student_ID  ); 
System. out .print In ( "Transaction  Name"  + 
current . get_transaction_name ()); 

System. out .println( "  Commit  the  transaction  "); 
current. commit (true) ; 

System. out . print In ("The  transaction  has 
been  commited"); 


}//end  of  try 
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catch  (  java.lang. Except ion  e  ){ 

System,  err  .println(  "No  transaction  -  rollback:  \n  "  + 

e  > ; 

try  { 

System. out. print In ("Current  Transaction  is  rolling 

back" ) ; 

current . rollback ( ) ; 

}//end  of  try 

catch (  org.omg.CosTransactions.NoTransaction  nt)  { 

System. err. print In ("\nNo  transaction  "  +  nt  ); 

System. exit (  1  ); 

}//end  of  second  catch 
}//end  of  first  catch 
}//end  of  add  course  method 
public  void  dropCourseO  { 
try  { 

//  get  current 

org.omg.CosTransactions. Current  current  = 

getCurrent ( ) ; 

System. out .print In ( "Begin  a  transaction."); 
current . begin ( ) ; 

System. out . print In (dropCourseTextField.getText () ) ; 
data  = 

orblet . drop_course 

(dropCourseTextField.getText  ( )  ,  student_ID, 
password,  studentNameTextField.  getText ( ) )  ; 
System. out .print In ("!!!!  I  !  "  +  data [ 0 ] . index_number  ) ; 
System. out . print In ( "In  dropCourse") ; 

System. out .print In ( "Call  Commit  the  transaction"); 
System. out .print In ( "Transaction  Name"  + 
current . get_transaction_name ( ) ) ; 

//  Commit  the  transaction 
current .commit (true) ; 

System. out .print In ( "The  transaction  has  been 
commited" )  ; 

}//end  of  try 

catch  (  java.lang. Except ion  e  ){ 

System. err. println( "No  transaction-rollback: \n  "+e  ); 
try  { 

System. out .println( "Current  Transaction  is 
rolling  back"); 
current . rollback ( ) ; 

}//end  of  try 

catch (  org.omg.CosTransactions.NoTransaction  nt)  { 

System. err. println ( "\nNo  transaction  "  +  nt  ); 

System. exit (  1  ); 

}//end  of  second  catch 
}//end  of  first  catch 
}//end  of  dropCourse  method 

private  org . omg . CosTransac t ions . Current  getCurrent ( )  { 

System. err .println ( "Session:  Resolve  TransactionCurrent  to 
get  access  to  Current  object."); 


try  { 
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org.omg.CORBA. Object  obj  = 

orb.resolve_initial_references ( " Transact ionCurrent " ) 

org.omg.CosTransact ions .Current  current  = 

org . omg . CosTransact ions . CurrentHelper . narrow (  obj  ) ; 

if(  current  ==  null  )  { 

System. err. print In ( "current  is  not  of  expected 

type ■ ) ; 

}//end  of  if 
return  current; 

}//end  of  try 

catch  (  java. lang. Exception  e  ) 

{ 

System. err. pr in tin (e) ; 
return  null; 

}//end  of  catch  block 
}//end  of  getCurrentO 

public  void  displaySchedule ( )  { 

System. out .print In ( "Display  Schedule"  ); 
dataModel . f ireTableDataChanged { ) ; 

/ /createTable ( ) ; 

}//end  of  displaySchedule  method 
public  JScrollPane  createTable ( )  { 

System.out . print In ( "createTable  method  is  called"); 

//  Create  a  model  of  the  data. 

//  TableModel  dataModel  =  new  AbstractTableModel ( )  { 
dataModel  =  new  Default TableModel ( )  { 

//  These  methods  always  need  to  be  implemented, 
public  int  getColumnCount ( )  {  return  names . length;  } 

public  int  getRowCount ( )  {  return  data . length; } 
public  java. lang. Object  getValueAt ( int  row,  int  col) 

{ 

if  (data[0] . index_number .equals ( " " ) ) 
return  " " ; 
if (col==0 ) 

return  data [row] . index_number; 
else  if(col==l) 

return  data [row] . course_code; 
else  if ( col==2 ) 

return  data [row] .section; 
else  if(col==3) 

return  data [row] . course_name; 
else  if(col==4) 

return  data [row] .meeting; 
else  if(col==5) 

return  data [row] .credits; 
else  if(col==6) 

return  data [row] .student_ID; 
return  " " ; 

}//end  of  getValueAt  method 

//  The  default  implementations  of  these  methods  in 
//  AbstractTableModel  would  work,  but  we  can  refine 
/ / them . 

public  String  getColumnName (int  column) 
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{ 

} 


return  names [column] ; 


public  boolean  isCellEditable (int  row,  int  col) 

{ 

return  (col==4) ; 

} 

public  void  setValueAt (java. lang. Object  aValue, 

int  row,  int  col) 

{ 

if (col==l) 

data [ row] . index_number  =  ( String ) aValue ; 
else  if (col==2) 

data [ row] .course_code  =  (String) aValue; 
else  if(col==3) 

data [row] .section  =  (String) aValue; 
else  if (col==4) 

data [row] . course„name  =  (String) aValue; 
else  if (col==5 ) 

data [row] .meeting  =  (String) aValue; 
else  if(col==6) 

data [row] .credits  =  (String) aValue; 
else  if (col==7) 

data [row] . student_ID  =  (String) aValue ; 
}//end  of  setValueAt  method 
};  //end  of  DefaultTableModel  definition 

JTable  tableView  =  new  JTable (dataModel) ; 

JScrollPane  scrollpane  = 

JTable . createScrollPaneForTable ( tableView) ; 
return  scrollpane; 

}//end  of  JScrollPane  createTable  method 

public  static  void  main (String  args [ ] )  { 

JavaORB .Trace . setTraceFile ( "bug. log" ) ; 

JavaORB . Trace . setTraceLevel ( 4 ) ; 
try  { 


//  1. 

//  Initialize  the  ORB 

orb  =  org.omg.CORBA.ORB.init(args,null); 
org. omg.CosTransact ions. Boot .ini t(  orb  ); 

//  2. 

//  Get  the  Calculator  reference  from  a  file 
orblet  =  null; 
obj  =  null; 
try  { 

java. io.Filelnput Stream  file  =  new 
java.io.Filelnput Stream ( "Objectld" ) ; 
java.io.DatalnputStream  mylnput  =  new 
java. io.DataInputStream(f ile) ; 

String  stringTarget  =  mylnput.readLineO ; 
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obj  =  orb.  string__to_object  (stringTarget)  ; 

JavaORB.util.IORManager  ior__manager  = 
new  JavaORB . ut il . IORManager ( )  ; 
JavaORB. util . IORBag  ior_bag  =  null; 
ior_bag  =  ior_manager . extract (  obj  ); 
System. out .print In (" ") ; 

System. out .print In ( "IOR  dump 

result” ) ; 

System. out .println( 

System. out .println (" HOP  version  : 

+  ior_bag. version. major  +  " . ”  + 

ior_bag. version. minor  ); 
System. out .println ( "Host  name  :  "  + 
ior__bag.host  )  ; 

System. out. print In ("Port  number  :  " 
+  iorjsag.port  ); 

System. out .println ( "Object  id  :  "  + 
ior_bag.id  ); 

System. out. print In ("Object  key  :  " 

+  new  String (  ior_bag.key  )); 
System. out .println ( " " ) ; 

JavaORB . Trace . setTraceFile 

("bug. log" ) ; 

JavaORB . Trace . setTraceLevel ( 4 ) ; 
}//end  of  try 

catch  (java. io . IOExcept ion  ex  ) 

{ 

System. out .println ("File  error") ; 

System. exit (0) ; 

}//end  of  catch 

//  3. 

//  Narrow  the  object  reference 
orblet  =  RegisterHelper. narrow (obj ) ; 

//  Use  the  client  object 
new  Client ( ) ; 

}//end  of  try 
catch  (Exception  e) 

{ 

System. out .println ( "Cannot  connect  to  ORB  for 

Register" ) ; 

return ; 

}//end  of  catch 
}//end  of  main 

public  Dimension  preferredLayoutSize (java . awt . Container  c) { 
return  origin; 

} 

public  Dimension  minimumLayoutSize ( java . awt .Container  c) { 
return  origin; 

} 

public  void  addLayoutComponent (String  s.  Component  c)  {} 
public  void  removeLayout Component (Component  c)  {} 
public  void  layoutContainer (java . awt .Container  c) 

{ 
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Rectangle  b  =  c . getBounds ( ) ; 
int  topHeight  =  90; 
int  inset  =  4; 

dropC ours eBut ton . setBounds (b.width-2*inset-130,  inset,  120, 

25)  ; 

addCourseButton. setBounds (b.width-2*inset-130,  32,  120, 

25); 

showRegisteredCoursesButton . setBounds (b . width-2  * inset-13  0 , 

60,120,25) ; 

dropCourseTextField. setBounds (b. width-225,  inset,  60,  25); 
addCourseTextField. setBounds (b. width-225,  32,  60,  25); 
studentNameTextField. setBounds (b. width-520,  32,  125,  25); 
courselndexNumberLabell. setBounds (b. width-375,  inset,  140, 

25); 

courseIndexNumberLabel2. setBounds (b. width-375,  32,  140, 

25)  ; 

addCourseStudentNameLabel . setBounds (b. width-625 ,  32,  100, 

25)  ; 

tableAggregate . setBounds (new  Rectangle ( inset , 

inset  +  topHeight, b. width-2* inset, 
b.height-2*inset  -  topHeight) ) ; 
}//end  of  layoutContainer  method 
}//end  of  client  class. 
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APPENDIX  E:  REGISTRATION  CLASS  IMPLEMENTATION 

// - 

//Filename  :  : Regis t ra t ionlmpl . java 

//Date  :01  Jan  2000 

//Subject  :Master  Thesis 

//Compiler  :Sun  JDK1.3 

// - 

import  j  ava . sql . * ; 

import  java. util . *; 

import  j  ava . net . * ; 

import  org . omg . CORBA . * ; 

import  org. omg. Project.*; 

import  org . omg . CosTransactions . * ; 

import  transaction. util.*; 

public  class  Registrationlmpl  extends  _RegisterImplBase 

{ 

Connection  connection; 

Statement  statement  ; 

ResultSet  resultSet  ; 

String  [  ]  columnNames  =  { } ; 

Class []  columnTpyes  =  {}; 

Vector  rows  =  new  VectorO; 

String  url  =  " jdbc : odbc : Sybase”  ; 

String  driverName  =  "sun. jdbc .odbc . JdbcOdbcDriver" ; 

String  databaseUser="yhazir" ; 

String  databasePassword="yh7093 " ; 

ResultSetMetaData  metaData; 

String [] []  classes; 
private  Lock  lock; 

/  ** 

*  Reference  to  the  ORB 
*/ 

org . omg . CORBA . ORB  _orb  ; 
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j ** 

*  Reference  to  the  resource 
*/ 

myResource  r  =  null; 

org.omg.CosTransactions. Current  current  =  null; 
org.omg.CosTransactions. Coordinator  coordinator  =  null; 
org.omg.CosTransactions.RecoveryCoordinator  recCoordinator  = 

null 

public  Regis trat ionlmpl  (org.omg.CORBA. ORB  orb) 

{ 

_orb  =  orb; 

lock  =  new  Lock ( ) ; 

if (  _orb  ==  null  )  { 

System,  err.  print  In  ( "orb  is  not  of  expected  type"); 

} / / end  of  if 
r  =  new  myResource ( ) ; 
orb. connect (  r  ); 

}//end  of  Regis trat ionlmpl  constructor. 

/** 

*  add_course  Operation 

* 

*  This  operation  can  be  used  in  a  transactional  mode 
*/ 

public  synchronized  course []  add_course ( String 
Index^umber,  String  Student_ID,  String 
password,  String  student_Name) 
throws  Unava i 1 abl e C ours  e 

{ 

boolean  commit  =  false  ; 

course []  mycourseSeq  =  new  course [100]; 

try  { 

markForTransactionBegin( ) ; 

Class  .  forName  (driverName)  ; 

System. out .print In ( "Opening  db  connection  in 

add_course" ) ; 
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connection  =  DriverManager .getConnection (url, 

Student_ID,  password) 
statement  =  connection. createStatement () ; 
for  (int  i=0;i<  100;i++) 

mycourseSeq  [  i  ]  =  new  course  ( " "  #  " 11 ,  " " , 

n  it  ii  n  tt  ti  ti  n  \  . 

/  /  /  /  / 

if  (connection  ==  null  | |  statement  ==  null) 

{ 

System. err. print In ("There  is  no  database  to 
execute  the  query."); 
markForRollbackO  ; 
return  null; 

}//end  of  if 

System,  err  .print  In  (Index_Number)  ; 

Sy  s  t  em .  er  r .  print  In  ( s  tuden  t_Name )  ; 

String  str  =  new  String ( " INSERT  INTO 
REGISTERED_COURSES 
(IndexJtfumber,Course_Code, Section, 

Cour  se_Name , Meeting, Credits  )  "  + 

" \nSELECT  Index_Number, Course_Code, Section, 
Course_Name, Meeting, Credits  ■  +  " \nFROM  courses 

WHERE  Index_Number  = "  +  " \ "  +  Index_Number  + 

n  \ ' " )  ; 

System,  out  .print In  (str)  ; 

int  returnVal  =  statement . executeUpdate (str) ; 

str  =  new  String ( n \nupdate 

REG  I  ST  ERED__C  OURS  E  S  set  Student^ID  =" 

+  "‘V"  +  student_Name  +  "\/n  +"  \nwhere 
Index^Number  ="  +  "V"  + 

Index_Number  +  " \ ' " )  ; 

System. out .print In (str) ; 

returnVal  =  statement . executeUpdate (str) ; 
if (returnVal  ==  0) { 

throw  new  Unava ilableC our se ( "ERROR 
IN  SQL  Statement  or  Primary 

Key" ,  Index_Number)  ; 

}//end  of  if 
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resultSet  =  statement . executeQuery 
( " SELECT  Index_Number , Course_Code , 

Section,  Course_Name,  Meeting,  Credits, 

Student_ID  FROM  REGISTERED_COURSES  "); 
metaData  =  resultSet . getMetaData () ; 

//  Get  all  rows, 
rows  =  new  Vector (); 
int  rowcount=0; 
while  (resultSet .next ( ) ) { 

Vector  newRow  =  new  Vector ( ) ; 

for  (int  i  =  l;i  <=  metaData .getColumnCount () ; 

i++) 

{ 

if  (i«l)  { 

mycourseSeq[rowcount] . index_number 
=  resultSet . getString ( i ) ; 

continue; 

}//end  of  if 
else  if (i==2) { 

mycourseSeq[rowcount] .course_code  = 
resultSet .getString (i) ; 

continue; 

}//end  of  else  if 
else  if (i==3)  { 

mycourseSeq[rowcount] . section  = 

resultSet . getString ( i ) ? 

continue; 

}//end  of  else  if 
else  if (i==4) { 

mycourseSeq[rowcount] . course^name  = 
resultSet.getString(i) ; 

continue; 

}//end  of  else  if 
else  if (i==5) { 

mycourseSeq[rowcount] .meeting  = 

resultSet .getString (i) ; 

continue; 
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}//end  of  else  if 


else  if (i==6) { 

mycourseSegtrowcount] .credits  = 

resultSet .getString(i) ; 

continue; 

}//end  of  else  if 
else  if (i==7) { 

mycourseSegtrowcount] . student_ID  = 
resultSet .getString(i) ; 

continue; 

}//end  of  else  if 
}//end  of  for 
rowcount++; 

}//end  of  while 
resultSet . close ( )  ; 
statement . close ( )  ; 
commit  =  true; 

}//end  of  try 

catch  (UnavailableCourse  uac) 

{ 

System. out .print In ( " \n  ERROR  IN  SQL  Statement  or 

PK")  ; 

System. err. print In ( "\n  This  course  is  not  available 

in  database ."); 

System. err. println ( "\n  Unavailable  Course  Name  : n  + 

uac . course_name  ) ; 

markForRollback ( ) ; 

}//end  of  catch  block 
catch  (SQLException  sgl) 

{ 

System. err .println ( "Cannot  connect  to  this 

database . " ) ; 

System . err . println ( sgl ) ; 
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markForRollback { ) ; 

}//end  of  catch  block 

catch  (ClassNotFoundException  ex)  { 

System. err. print In ( "Cannot  find  the  database  driver 

classes . " ) 

System. err .print In (ex) ; 
markForRollback ( )  ; 

}  //end  of  catch  block 
finally  { 

//  Commit  or  rollback  the  transaction, 
if  (commit)  { 

System. out .println (" ***  Committing  transaction 

****»)  . 

markForCommit ( ) ; 

}//end  of  if 
else 


{ 

System. out .print In ("***  Rolling  back 

transaction  ***" ) ; 

markForRollback ( ) ; 

}  //end  of  else  if 
}//end  of  finally  block 

System. out. println ("#####################") ; 
for(int  ix  =  0;  ix  <  10;  ix++)  { 

System. out . println ( "Student  ID="  + 

mycourseSeq[ix] . student_ID) ; 

} 

return  new  courseSeqHolder (mycourseSeq) .value; 

/ /return  mycourseSeq; 

}//end  of  add_course  method 

public  synchronized  course []  drop_course (String 

course_index_number ,  String  Student_ID , 
String  password.  String  student_Name) 
throws  UnavailableCourse  { 
boolean  commit  =  false  ; 
course [ ]  mycourseSeq  =  new  course[100]; 
try  { 
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markForTransactionBeginO ; 

Class .  f  orName  (driverName)  ; 

System. out .println ("Opening  db  connection  in 
drop_course" )  ; 

connection  =  DriverManager .getConnection (url, 
Student_ID,  password) ; 
statement  =  connection.createStatement ( ) ; 
for  (int  i=0;i<  100;i++) 

mycourseSeq [ i ]  =  new  course ( " " ,  " n ,  " " ,  " " ,  " " , 

11  II  VI  n  \  . 

/  /  / 

if  (connection  ==  null  | |  statement  ==  null)  { 

System. err. print In ("There  is  no  database  to 
execute  the  query. " ) ; 

return  null; 

}//end  of  if 

int  returnVal  =  statement .executeUpdate ( "DELETE  FROM 

REG I STERED_COURSES 
WHERE  INDEX_NUMBER  =  " 

+  "  \  + 

c  our  s  e__i  ndex_numbe  r 

it  \  /  it  +  n 

AND  Student_ID  ="  + 

"  \  ' "  + 

student_Name  +  " \ '  ; " ) ; 

if (returnVal  ==  0) { 

throw  new  UnavailableCourse ( "ERROR  IN  SQL 
Statement  or  Primary  Key" , 
course_index_number)  ; 

}//end  of  if 

resultSet  =  statement . executeQuery ( "SELECT 

Index_Number7  Course_Code,  Section, 
Cour se_Name ,  Meeting , 

Credits, Student_ID 
FROM  REGIS TERED_COURSES  " ) ; 
metaData  =  resultSet.getMetaDataO ; 

//  Get  all  rows. 
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rows  =  new  Vector (); 

int  rowcount=0; 

while  (resultSet .next ( ) ) { 

Vector  newRow  =  new  Vector () ; 

for  (int  i  =  1;  i  <=  metaData . getColumnCount ( ) ; 


if (i==l) { 

mycourseSeq[rowcount] . index_number  = 

resultSet .getString(i) ; 

continue; 

}//end  of  if 
else  if (i==2) { 

mycourseSeq [rowcount] .course_code  = 
resultSet . getString ( i ) ; 

continue; 

}//end  of  else  if  block 
else  if (i==3) { 

mycourseSeq[rowcount] .section  = 

resultSet .getString (i) ; 

continue; 

}//end  of  else  if  block 
else  if (i==4) { 

mycourseSeq[rowcount] . course_name  = 

resultSet .getString(i) ; 

continue; 

}//end  of  else  if  block 
else  if (i==5) { 

mycourseSeq [rowcount ] .meeting  = 

resultSet . getString ( i ) ; 

continue; 

}//end  of  else  if  block 
else  if ( i— = 6 ) { 

mycourseSeq [rowcount] .credits  = 

resultSet .getString (i) ; 

continue; 
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}//end  of  else  if  block 
else  if (i==7) { 


mycourseSeq[rowcount] . student_ID  = 
resultSet . getString (i) ; 
continue; 

}//end  of  else  if  block 

System. out .print In (classes [rowcount] [i] ) ; 
}//end  of  for 
rowcount++; 

}//end  of  while 
commit  =  true; 

}//end  of  try 

catch  (UnavailableCourse  uac) { 

System. out. println ("\n  ERROR  IN  SQL  Statement  or  PK"); 
System. err .print In ( "\n  This  course  is  not  available  in 

database . " ) ; 

System. err .print In ( " \n  Unavailable  Course  Name  : "  + 

uac . course_name  ) ; 

markForRollback( ) ; 

}//end  of  catch  block 
catch  (SQLException  sql) { 

System. err. print In ("Cannot  connect  to  this  database."); 
System.err.println(sql) ; 
markForRollback ( ) ; 

}//end  of  catch  block 

catch  (ClassNotFoundException  ex)  { 

System. err .println( "Cannot  find  the  database  driver 
classes ."); 

System. err .println (ex) ; 
markForRollback ( ) ; 

}//end  of  catch  block 
finally  { 

//  Commit  or  rollback  the  transaction, 
if  (commit)  { 

System. out .println (" ***  Committing  transaction  *** 
markForCommit ( ) ; 

}//end  of  if 
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else{ 


System. out. printing***  Rolling  back  transaction 

*  *  * » )  . 


markForRollback ( ) ; 

}//end  of  else  if  block 
}//end  of  finally  block 

return  new  courseSeqHolder (mycourseSeq) .value; 
}  //end  of  drop_course  method 


public  void  markForTransactionBegin ( ) { 

//  This  operation  register  a  resource  and  mark  transaction 

to  be  rollbacked  only 


try  { 

//lock  add_course 
lock. lock( ) ; 

//  get  current 
current  =  getCurrent ( ) ; 

System. out .println (" start  transaction") ; 
current . begin ( ) ; 

//  get  control  and  coordinator 

String  transName  =  current  .get__transaction_name  ()  ; 
System. out .println ( " Regis trationlmp : name  of  the 
transaction  :  "  +  transName) ; 

org.omg.CosTransactions .Status  currentStatus  = 
current . get_status { ) ; 

System.out.println("RegistrationImpl:  status  of  the 
transaction:  "  +  current Status .value ()) ; 

System. err .println ( "Regis trationlmpl :  get  control") ; 
Control  control  =  current .get_control () ; 

System . err . println ( " Regis trationlmpl :  get 

coordinator" ) ; 

coordinator  =  control . get_coordinator ( ) ; 

//  register  resource 
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System. out .print In ( "Registrationlmpl :  register 

resource  with  OTS"); 

recCoordinator  =  coordinator  .register__resource  (  r  ); 
}//  end  of  try  block 


catch  (  java. lang. Exception  e  ) 

{ 


} 


System. err .println( "markForTransactionBegin  catch 
block\n"  +  e) ; 


}//end  of  markForTransactionBegin  method 
public  void  markFor Rollback ( ) { 
try  { 


//unlock  add_course 
lock. unlock ( ) ; 

coordinator . rollback_only ( ) ; 
}//end  of  try  block 
catch  (  java. lang. Exception  e  ) 

{ 


System. err. println(e) ; 
throw  new  org . omg . CORBA . BAD_PARAM ( ) ; 
}//end  of  catch  block 
}//end  of  markForRollback ( ) 


public  void  markForCommit ( )  { 

try  { 

//unlock  add_course 
lock. unlock ( ) ; 

org. omg. CosTransact ions. Status  currents tatus2  = 

current . get_status ( ) ; 

System. out .print In ( "Registrationlmpl :  status  of  the 

transaction:  "  +  currentStatus2 .value () ) ; 
current .commit (true) ; 

System. out .println ( "Transaction  has  been  Committed"); 
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org . omg . CosTransactions . Status  currentStatus3  = 

current . get_status ( ) ; 
System. out .print In ( "Regis trationlmpl :  status  of  the 
transaction:  "  +  currentStatus3 . value ( ) ) ; 

}  //end  of  try  block 

catch  (  java. lang. Except ion  e  )  { 

System. err .println(e) ; 
markForRollback ( ) ; 

}//end  of  catch  block 
}//end  of  markForCommit ( ) 


private  org. omg. CosTransactions .Current  getCurrentO  { 

System. err .println ( "Session:  resolve  transaction  current") 
try  { 

org. omg. CORBA. Object  obj  = 

_orb. resolve_initial_references 

( " Transact ionCurrent " ) ; 

current  = 

org . omg . CosTransactions . CurrentHelper . narrow (  obj  ) ; 
if (  current  ==  null  )  { 

System. err. print In ( "current  is  not  of  expected 
type " ) ; 

} //end  of  if 
return  current; 

}//end  of  try 

catch  (  java. lang. Exception  e  ) 

{ 

System. err .print In (e) ; 
return  null; 

}//end  of  catch  block 
}//end  of  getCurrentO 
}  //end  of  Registrationlmpl  class 
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APPENDIX  F:  LOCK  CLASS  IMPLEMENTATION 


// - 

//  Filename  :  Lock. java 
//  Date  :  01  Jan  2000 

//Subject  :  Master  Thesis 
//  Compiler  :  Sun  JDK1.3 
// - 


package  transaction. util; 

public  class  Lock  { 

private  boolean  locked; 

public  Lock()  { 
locked  =  false; 

}//end  of  Lock  constructor 

synchronized  public  void  lock()  { 
while (locked)  { 
try  { 

this .wait ( )  ; 

}//end  of  try 

catch (InterruptedException  e)  { 
}//end  of  catch 
}//end  of  while 
locked  =  true; 

}//end  of  lock  method 


synchronized  public  void  unlock ()  { 
locked  =  false; 
this .notifyAll ( ) ; 

}//end  of  unlock  method 
}  /  /  end  of  Lock  class. 
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APPENDIX  G:  APPLICATION  PROGRAM  GUI  SCREEN  SHOTS 


I.  Connection  To  a  Database 


I gH  Connection  Information 


User  name: _ | 

Password: _ 

:  : |  1  : ' 

tonnect  I 


Adding  a  new  course  from  the  Course  Table  to  Registered  Course  Table 


m  Register  a  Course 


f  V 

Student  Name  0. Clinton 


Course  Index  Number 

■  . . ■ 

Course  Index  Number  2000 


3T4 _ 4+1_ 

I  Advanced  Java  IM3T3W4T5F5  2+1 


I  Advanced  C++  M1T1W2T3  2+1 


Operating  Syt..lM4T3W5 
M2W3F3 


M4T4W4  4+1 


Drop>  Course 


C.Eagle 

T.Wu 


Y.Hazir 


B.  Clinton 


3, 


Dropping  a  course  from  the  Registered  Course  Table 


llH Register  a  Course 

!|  ;  •  >  ••  . 

Course  Index  Number 

2000 

Drop  Course 

Student  Name 

B.CIinton 

Course  Index  Number 

Add  Course 

If  j  . 

• 

■  ■  ■'  -■■■  ■  /, lv  • 

II  Index  Number 

Course  Code 

Section 

Course  Name 

Meeting 

Credits 

si 

CS 

2 

Introduction  J... 

M3T4 

4+1 

C.Eagle 

irawi 

CS 

2 

Advanced  Java 

M3T3W4T5F5 

2+1 

T.Wu 

1  7000 

CS 

1 

Advanced  C++ 

M1T1W2T3 

2+1 

Y.Hazir 

3000 

CS 

1 

Operating  SyL. 

M4T3W5 

5+1 

M.Daglar 

;t  1000 

1 

Database 

M2W3F3 

4+1 

E.Hazir 

;!f  . 

| 

'< 

1 

|| 

|. 

ix 

. - . - . 

j- 

1 

t  -  v  7 . . 

•••— r . - . .  .  - 

- . . -  -  ■  • 

. i . . . . i 
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APPENDIX  H:  CLIENT  \  SERVER  DOS  OUTPUT  SCREEN  SHOTS 

1.  Begin  the  JAVAORB  Object  Transaction  Service(OTS) 


*§  Command  Prompt  -  ots 


H :\JaoaORB\exaroples\Pro ject>ots 
JauaORB  Cos Trans act  ions 
uersion  1.0 

Xauier  Blanc  &  Jerone  Daniel 
OTS  seruer  is  now  ready _ 


2.  Start  the  Server  Program 


H  :  \JavaORB\examples\Pro ject >H  :  \  jdkl  .2  -  2\hin\ java  -DJfiUfi„ORB_DI R=H :  \Jav aORBVbin  Client 

I  OR  dump  result 

IIOP  version  :  1.2 
Host  name  :  Boreas 
Port  number  :  1157 

Object  id  :  IBL:Pro ject/Register :1 .0 
Object  key  :  IDL:Pro ject/Register :1 .0/1 

createlable  method  is  called 

Session:  Resolve  Transact io nCurr e n t  to  get  acces 
Begin  a  transaction. 

1008 

Eagle 

Transaction  NaroeTransact ion  numero  :  1 
Call  Commit  the  transaction 
Commit  the  transaction 
|The  transaction  has  been  commited 


to  Current  object. 
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Start  Client,  make  connection  to  Database  and  Use  Add  and  Drop  Functions 


I  r-'5  Command  Prompt  -  H:\jdk1-2.2\bin\java  -DJAVA ORB DIR=H:\JavaORB\bin  Client 


in  :\JauaORB\examples\Pro ject  >H  :\ jdkl .  2 . 2\bin\jaua  -DJAUA_ORR __DI  R-H  :\Jau<iORB\bin  Client 

I I  OR  dump  result 

III  OP  version  :  1.2 
gHost  name  :  borcas 
IPort  number  :  1157 

IObject  id  :  I DL : Pro ject/Rcgister : 1 . 6 
IObject  key  :  I DL : Pro jee t/Eegister : 1 . 0/1 

IcreateTable  method  is  called 
ISession:  Resolve  Transact ionCurrent 
gBegin  a  transaction. 

11000 

Eagle 

IT ran s act  ion  NameTransact ion  numcro 
I Call  Commit  the  transaction 
Commit  the  transaction 
iThe  transaction  has  been  comnited 
ISession:  Resolue  Transact ionCurrent 
1 Be gin  a  transaction. 

12000 

Eagle 

■Transaction  NameTransact ion  numcro 
ICall  Commit  the  transaction 
Commit  the  transaction 
iThe  transaction  has  been  comnited 


to  get  access  to  Current  object. 


:  1 


to  get  access  to  Current  object. 


|H  : \JavaOKB\examplesNPro  ject>H  :\jdkl  .2  .2\binSjava  -DJflUft_ORB „DI  R-H  :\JavaORB\bin\  Server 
■Starting  the  ORB... 

1 1  OR  dump  result 

I  OP  version  :  1.2 
iHost  name  :  borean 
I Port  number  :  1157 

■Object  id  :  I DL: Pro ject/Regic ter : 1 . 0 
IObject  key  :  I DL: Pro ject/Regis ter : 1 . 8/1 

iThe  server  is  ready. . . 

ISession:  resolve  transaction  current 
is tart  transaction 

|RegistrationImp:nane  of  the  transaction  :  Transaction  nwncro  :  2 
[Registrat ionlmpl:  status  of  the  transaction:  0 
iRegistrat ionlmpl:  get  control 
[Registrat ion  1 mpl :  get  coordinator 
■Registrat ionlmpl :  register  resource  with  OTS 
■Opening  db  connection  in  add_course 

V 1800 

[E.Hazir 

[INSERT  INTO  REGI STERED_COUHSES  <  I ndex_Number „ Course_Code , Sec t  ion  ,Course_Nane Meet  ing„Credit 
i SELECT  I nde  x_Number . Course _Code .Section, Course  _Nane . Meet ing , Cred its 
iFROM  courses  UHERE  Index_.Nunber  -*1088' 

[update  REGISTERED_COURSES  set  Studcnt_ID  -'E.Hazir' 

■where  Index_Nunber  ='1880' 

!*<•*«*  Committing  transaction 

I Registrat ion  I npl :  status  of  the  transaction:  0 
| Resource  :  PREPARE 
I Resource  :  COMMIT 
I Resource  :  FORGET 
ITransaction  has  been  Committed 

iRegistrationlmpl:  status  of  the  transaction:  6 

■Student  ID=C.Eagle 
IS  t  ude n t  I  D T  .  Uu 
[Student  ID-V.Hazir 
[Student  ID-M.Daglitr 
IStudent  ID=E.Haair 
■Student  ID= 

■Student  ID= 

■Student  ID= 

■Student  ID- 
■Student  ID= 


B 


s  > 


APPENDIX  I:  DATABASE  TABLES  SCREEN  SHOTS 


^Microsoft  Access 

gpigM 


Insert  Format  gecords  look 


lip  Sybase:  Database  : 


#  Repots  j  3  rtem  ]  ftxxte  j  '  - 

1  Courses 

s^?~'®^^s^z>^4»rxj:+jia^,y!ZS2!i&.<xz;xA.\  •  r.  .  -  WAA-i£i 

m*rn- 

1  SH 

1  a*  I 

0:  Courses;  Tablis 


M  Regislered Courses  :  T able 


12 

Introduction  Jav! 

!i 

Database 

!i 

Operating  Syter 

|2 

Advanced  Java 

M 

Advanced  C++ 

Student  ID 


C.Eagle _ 

EHazir 
M.Daglar 
TWu  _ ' 
Y.Hazir 
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